Two weeks. A compliance team of four people. Three tools built, tested, and handed off. Here is what that actually looks like.
Week 1, Days 1-2: Discovery
We start with the boring part. What compliance data sources does the team currently use? Where does the data live? What is the report that takes three days to produce manually? Who reads it? What decisions does it inform?
In a typical fintech discovery session, we find: a primary database with transaction records, a secondary system for customer KYC data, a spreadsheet that someone maintains manually with regulatory filing deadlines, and a Slack channel where anomalies get reported in free text.
The three-day report is usually a monthly regulatory filing that requires pulling data from two systems, cross-referencing transactions against customer risk scores, formatting the output in the regulator's required structure, and having a senior compliance officer review it before submission.
This is the target. Everything we build in the next eight days is scoped to make this process faster, more accurate, and owned by the team.
Week 1, Days 3-5: Design and build begins
Day 3 is design. We map the reporting dashboard on a whiteboard (or screen share). What data fields does the regulator require? What filters does the compliance team need? What does the review workflow look like?
The team approves the design before a line of code is written.
Days 4-5, we build the first tool: the reporting dashboard skeleton. It connects to the existing database. It pulls transaction data and customer risk scores. It presents them in the format the regulator requires. The compliance team watches this happen in real-time via screen share. They see the Claude Code workflow. They start to understand the method.
By end of day 5, the dashboard shows real data in the required format. It is not pretty yet. But it works.
Week 2, Days 1-3: Build continues
Day 6: the audit trail generator. Every time a compliance team member reviews a transaction, flags a risk, or approves a report, the system creates a timestamped, immutable log entry. Who did what, when, and why. This is the documentation that auditors ask for and that most teams produce retroactively (if they produce it at all).
Days 7-8: the risk flag tool. The compliance team defines the transaction patterns they care about: amounts over a threshold, velocity of transactions from a single account, geographic anomalies, pattern matches against known risk indicators. The tool scans the transaction database daily and surfaces anything that matches. No more Slack messages saying "hey, this looks weird." The weird things surface automatically.
Week 2, Days 4-5: Train and handoff
Day 9: the team drives. They use the dashboard. They modify a filter. They add a new risk flag pattern. They break something and fix it. We watch. We answer questions. We do not touch the keyboard.
Day 10: handoff. The team receives the complete codebase, the CLAUDE.md that governs how the code should be modified, and a written maintenance guide. The guide covers: how to add new report fields, how to modify risk flag patterns, how to update the dashboard when the regulator changes the filing format.
What the team owns at the end
Three tools they built alongside us. A reporting dashboard that turns a three-day process into a two-hour review. An audit trail generator that creates compliance documentation in real-time instead of retroactively. A risk flag tool that surfaces anomalies their team defined, not a vendor's generic model.
They own the code. No licensing fees. No per-seat pricing. No vendor dependency.
What they do not own
A dependency on us. When the regulator changes the filing format, the team modifies the dashboard themselves. When a new risk pattern emerges, they add it to the flag tool. The capability transferred with the code.
Book a governance sprint — every sprint is scoped to your team. Book a call to map out what yours would cover.
Get posts like this in your inbox
No spam. New articles on AI strategy, governance, and building with AI for small business.
Keep Reading
Why your fintech startup should treat CLAUDE.md like a compliance document
The configuration file that governs AI behavior in your codebase deserves the same rigor as your compliance policy.
Your company's data is leaving the building. Here's why your own LLM keeps it where it belongs.
Every time your team pastes patient records, transaction logs, or internal documents into a third-party AI tool, that data leaves your control. Building your own LLM changes the equation entirely.