The interesting decisions in a fintech AI build are not about the model. They are about everything around it — the audit log, the human override, the eval discipline, the model inventory. Each of these is a normal engineering concern in any AI system. Each is treated very differently when the system sits inside a regulated financial workflow
What follows is the lifecycle we run on every fintech AI engagement. Five phases. The decisions that get locked at each one. Where EU and US specifics genuinely differ, we tag inline. Where they do not — which is most places — assume both jurisdictions are in scope.
The Lifecycle
Phase 1 — Scope and Classification
The first phase answers one question. Who do you have to satisfy.
[EU] The AI Act has a list — Annex III — of uses the EU has decided carry significant risk. Credit scoring, insurance underwriting, biometric verification sit on that list. Fraud detection, internal analytics, customer support usually do not. The classification triggers a long list of obligations or lets you skip them. The appliedAI enterprise study found 18% of systems land clearly in high-risk, and 40% sit in a genuinely ambiguous middle. Classification rationale matters more than which side of the line you land on.
[US] There is no single regulator to classify against. A typical fintech AI feature has to satisfy some combination of a bank partner running its third-party risk programme, NYDFS if the company holds any New York DFS license, the CFPB for credit decisions, state attorneys general for fair-lending exposure, and the GSEs for anything mortgage-adjacent. SR 26-2 explicitly excludes generative AI from its scope, but examiners still expect the same principles — materiality, ongoing monitoring, effective challenge. They just have no specific framework to point at.
In both jurisdictions, this phase produces nothing impressive. A short classification record that maps the system against what actually applies. It is not the deliverable that earns the project its budget. It is the one that decides whether everything done in the next four phases is being measured against the right standard.
Phase 2 — Architecture and Data
This is the phase that decides the audit. Five architectural decisions get locked here. None can be deferred without paying for a rebuild later.
Model inventory as code, not as spreadsheet. Every LLM call in the system needs a registered model_id, including third-party API-based models with version numbers logged per request. The most common SR 11-7 examination finding in 2024–2025 was LLMs deployed in customer service and document processing that were not in the model inventory because teams classified them as "tools" rather than "models." The tools-versus-models line is gone. If a system materially influences a financial decision, it is in scope. If the model inventory is a Notion page or a Confluence doc, you have already lost. The inventory needs to be queryable, versioned, and tied to the audit log at the request level.
The audit log schema, locked before retrieval architecture. This sounds backwards until you have done it once. Every downstream compliance artefact flows through the audit log. The schema captures model_id and version, prompt_hash, retrieved_context_ids, output, confidence score, latency per stage, and a stable request_id. Append-only storage. Hash-chained writes. [EU] Article 18 requires ten years of technical documentation retention, configured as a database lifecycle policy on day one. [US] For NYDFS-supervised entities, the schema must also capture what nonpublic information was accessed, by which system, under what authorisation, and when.
Data handling posture. [EU] Data residency is architectural — a region-aware gateway, a log store in the right cloud region, explicit model provider selection per jurisdiction. Bolting any of this on later costs months. [US] No federal data residency rules, but a patchwork of state privacy laws (California's CCPA/CPRA, plus Colorado, Texas, Virginia, Connecticut, Utah, and growing) requires region-aware logging and per-state data handling as a first-class feature, not an afterthought.
Human override as a technical control. A reviewer with policy authority is not a control. A reviewer with a button that stops the decision before it executes is. [EU] Article 14 of the AI Act states the principle plainly: technically enforced override capabilities, not procedural approval. [US] SR 26-2's effective-challenge principle expects the same in practice. Design the override into the system itself, not into the policy document. The latency budget for the override decision has to fit inside the user-facing transaction.
Vendor governance posture. When you call Anthropic, OpenAI, or Google through an API, you carry deployer-grade liability for compliance purposes. [EU] Article 26 makes the deployer liable regardless of who built the model. [US] The bank partner relationship cascades third-party risk obligations down to fintech vendors; for mortgage-adjacent products, Fannie Mae and Freddie Mac extend AI/ML governance to vendors and subcontractors through a "no less protective" standard. Either way, your vendor model versions are captured in the model inventory as if they were your own, and the contract with the provider gets read against those obligations rather than skimmed.
Of these five, model inventory is the one most teams skip — because it looks like documentation. It is not. It is the runtime registry that lets you answer "which model version produced this decision on June 3rd" in one query. Without it, every other compliance artefact becomes unverifiable.
Phase 3 — Build and Eval
Phase 3 is where the engineering happens. Less architecture, more discipline. Four habits define a compliance-centered build, and the architecture in Phase 2 either makes them easy to follow or impossible to enforce.
Prompt versioning treated as code. Every prompt change is a deploy. Every prompt is checked into version control with a hash, and the hash is what gets logged per request. An undocumented prompt change is a model change without a model change record.
Eval datasets composed with protected-class slices from day one. The standard fintech approach is to retrofit fair-lending tests after the model works. The compliance-centered approach is to compose the eval set with protected-class slices from the first thirty examples. The cost is identical at the start, and prohibitive at the end. [US] In July 2025, Massachusetts settled a fair-lending action against an AI underwriting model for $2.5 million — the state's complaint specifically cited the lender's failure to test the algorithmic models for disparate impact. The retrofit is what gets enforced against.
Faithfulness scoring as a first-class metric. For RAG systems handling regulated content — disclosures, adverse-action notices, account terms — the output must accurately reflect the retrieved source. The AI Act and the CFPB both require, in different language, that AI systems explain themselves in terms a deployer can verify and a user can understand. If the RAG output does not actually reflect the retrieved context, you are out of compliance in either jurisdiction. Tools exist for measuring faithfulness; the discipline is using them on every release, not when something visibly breaks.
Continuous bias testing for high-stakes classifications. Not an annual audit. Per-deploy regression checks against the same protected-class slices that ship in the eval set. If a prompt change drops faithfulness for one demographic, the CI gate catches it before the change lands.
Phase 4 — Pre-Deployment Gate
Before traffic flows, a set of deliverables has to exist. Each one is a hard gate. Not a milestone, not a target.
If Phase 2 was built correctly, most of these artefacts are exports from work already done. The model inventory becomes the spine of the technical documentation. The audit log schema becomes the evidence for ongoing monitoring. The Phase 3 eval results become the basis of every quality claim.
[EU] The DPIA covers personal data risk under GDPR. The FRIA covers fundamental rights risk under AI Act Article 27. Different scopes, different signatories. Both required for high-risk systems that process personal data. Both living documents that update when the system materially changes.
[EU] The conformity assessment under Article 43 applies to high-risk systems. It is a process, not a paragraph in a deck. Either it has been completed and certified before the deadline, or the system is operating illegally.
[US] NIST AI RMF mapping is the workhorse artefact: 72 subcategories across four functions — Govern, Map, Measure, Manage. Enterprise buyers, vendor security questionnaires, and state regulators all increasingly point at it as the de facto standard.
[US] The bank partner third-party risk attestation is the artefact most fintechs underestimate. The bank's programme will ask for evidence of every Phase 2 architectural decision and every Phase 3 discipline. The package gets assembled before deployment, not under pressure mid-launch.
The kill switch is the deliverable most often overlooked. The system must demonstrably stop, the invocation procedure has to be documented, and it has to be tested before deployment. A reviewer with a button is a control. A reviewer with policy authority but no button is not.
Engineering teams are used to soft deadlines. The artefacts in this phase are dates, not documents.
Phase 5 — Post-Deployment Monitoring
This is the phase that fails audits most often. Teams declare victory at deployment and treat ongoing monitoring as a stretch goal. The regulator does not.
Four controls run continuously from the day of deployment.
Drift monitoring on quality scores — rate-of-change, not absolute thresholds. We learned this one the painful way. A quiet provider-side tokenizer update once shifted currency-string parsing in a fintech support workflow, and it went unnoticed for two weeks because the absolute scores still looked acceptable. Rate-of-change alerts would have caught it in hours.
Model inventory as a living document. Re-validated when model versions change, not annually. When OpenAI deprecates a checkpoint or Anthropic ships a new model, the inventory updates the same day. Stale inventory is the same as no inventory.
Annotation queue feeding back into the eval set. Production failures get reviewed, labelled, and promoted into the golden set weekly. [US] For US fintechs, the queue should also capture customer complaints flagged for fair-lending or UDAAP review — leading indicators of enforcement letters arriving.
Annual certification readiness. [EU] Material changes to the system retrigger DPIA and FRIA updates and re-validation of the conformity assessment. [US] NYDFS-supervised entities file dual-signature CEO and CISO certification every April 15. In both cases, the discipline is keeping the evidence package live throughout the year, not assembling it the week before the deadline.
The alternative to compliance-centered development passes the launch audit. The compliance-centered approach passes every audit thereafter.
Closing
Compliance-centered AI development in fintech is not a documentation layer added at the end of a project. It is a series of architectural and disciplinary decisions made across the lifecycle, with the heaviest weight in Phase 2 and the easiest failures in Phase 5.
The regulations define the constraints. They do not define the engineering. Most fintech AI projects that fail an audit do not fail because the team misread the regulation. They fail because the architecture made the regulation impossible to comply with after the fact.
A companion post on the major architectural mistakes we see when teams build fintech AI the same way they build for other industries is coming next.