Production AI inside regulated finance
I'm Adam Boudjemaa. I ship production AI where a wrong answer is expensive: RAG that cites what it used and abstains when it can't, agents contained to least-privilege access, compliance enforced by the system rather than promised in a policy, and evals that gate the release. This is the engineering, not the pitch.
Regulated finance is the hardest place to run AI and the place I know from the inside. I solo-shipped an 11-agent GenAI platform for a US real-estate private-equity fund with roughly $3B AUM, and I'm one of the five named authors of ERC-3643, the Ethereum standard now used for $32B+ in tokenized securities. This page is the through-line across four field notes: the four things that actually change when the customer is a regulated financial institution, and how each one is built.
By Adam Boudjemaa · Published 2026-07-23 · Last substantially updated 2026-07-23
// THE THESIS
Why regulated finance is the proving ground
Most AI demos are graded on whether they answer. In a fund workflow, the interesting question is whether the system knows when not to. A hallucinated figure in a reconciliation is not a cute bug, it is a number a regulator might read. Access to the underlying data is scoped, audited, and legally bounded, so the hard engineering is often what you are not allowed to send where, not the model call.
That pressure is exactly why regulated finance is a good forcing function. It turns nice-to-haves into requirements: verified citation, evidence-based abstention, contained permission, a defensible audit trail, and one accountable owner from retrieval to answer. Build for that environment and the same system holds up anywhere. The four pillars below are how I make it concrete, and each links down to a field note that shows the build.
// THE APPROACH
Four pillars, and the field note behind each
Evidence-grounded RAG
The system cites what it actually used, and it declines when the evidence is not there. Verified citations plus evidence-based abstention beat a confident guess every time the answer sits near a fund's books.
▸ Verified citations and abstentionContainment and least privilege
Prompt injection is not going to be solved, so it gets contained. Money-moving actions run under scoped, revocable permission with a human gate, not on trust that the model behaved.
▸ Least privilege for agents that move moneyMachine-enforced compliance
Permission enforced by the system, not trusted at the caller. ERC-3643 does exactly this on-chain at transfer time; a retrieval pipeline does it with audit trails, prompt versioning, and human oversight you can evidence.
▸ The EU AI Act as an engineering checklistRelease-gating evals
Evals decide whether an agent ships, not whether a benchmark looks good. Abstention is scored as a first-class dimension, sitting next to red-team results in the gate.
▸ The eval suite that gates a releaseTHE PART MOST AI GUIDES SKIP
Compliance the system enforces, not the one it promises
The reason I keep pointing at ERC-3643 is that it already solved the problem AI security is now rediscovering. In ERC-3643 the token, not the caller, checks eligibility at transfer time. Permission is enforced by the system on every move, so a compromised or confused caller still can't do what it isn't allowed to. That is the same shape a regulated retrieval pipeline needs: scoped access, a human gate on the actions that matter, and an audit trail that lines up with a recognized control.
I've built this twice: ERC-3643's on-chain transfer checks, now carrying $32B+ in tokenized securities, and a regulated-finance RAG with abstention, verified citations, evals, and audit trails. The framework I use to make either one defensible is the FDE Evidence Ladder.
// PROOF
The record this is built on
Distinct systems, distinct numbers. The 11-agent fund platform and the 46 internal-ops agents at Integra were separate deployments, and I keep them separate.
11
Production agents shipped into a ~$3B AUM fund
$32B+
Tokenized on ERC-3643, a standard I named-authored
$441M
On-chain volume moved through account-abstraction rails
38M+
Transactions across that infrastructure
46
Internal-ops agents I deployed at Integra (2025-26)
3
Ethereum standards authored, plus one in progress
ERC-3643, the standard behind that compliance layer, earned one precise and limited distinction: Cited by name by the SEC Chairman. Cited, not endorsed, and that distinction is the whole point of writing standards that survive review instead of slideware that does not.
// FIELD NOTES
Read the field notes
Four practitioner write-ups, one per pillar. Each is a build log from real, forward-deployed work, not a survey.
Verified citations and abstention in RAG
The citation-verification-plus-abstention design that lets a system say 'I don't have enough to answer that' inside a regulated fund.
▸ Read the field noteLeast privilege for agents that move money
Containment after prompt injection stopped being solvable, borrowing the pattern ERC-3643 already runs at transfer time.
▸ Read the field noteThe EU AI Act as an engineering checklist
Article by article, what an engineer actually changes: what to log, how to version a prompt, and how to evidence accuracy.
▸ Read the field noteThe eval suite that gates a release
The release-gating suite that decided whether an agent went live, with abstention scored as a first-class dimension.
▸ Read the field noteCite this page
Boudjemaa, Adam. "AI in Regulated Finance: A Production Guide." adam-boudjemaa.com, 2026-07-23. https://adam-boudjemaa.com/ai-in-regulated-finance
Keep reading
Forward-Deployed AI Engineer
The role that ships this work: a production engineer embedded inside the customer's real environment.
The FDE Evidence Ladder
The framework: how a system climbs from a demo to a regulator-defensible deployment.
The Ethereum standards
ERC-3643, ERC-6960, ERC-7410, and the machine-enforced compliance that started on-chain.