Why Banking Still Doesn't Have an AI Architecture—And What I Built to Fix It
Twelve years at Citibank and two at Bloomberg taught me one thing: banks don't need better models. They need an architecture that respects how banks actually work.
By Sandro Garcia
In 2015, I was sitting in a Citibank operations room in Buenos Aires, watching a conciliation batch fail because an Oracle stored procedure had a date-format mismatch with a SQL Server instance from an acquisition three years prior. The fix took four hours. The business impact was zero—because the batch was designed to fail safe, alert, and wait for human validation.
That night, I learned something that no consultant deck will ever teach you: banks are not broken. They are engineered to survive failure.
The AS/400 that runs your wire transfers was not designed to be "modern." It was designed to never lose a penny. The SQL Server that holds your AML alerts was not built for real-time API consumption. It was built to generate a report that a compliance officer can print, sign, and file. The data warehouse that feeds your regulatory reporting runs at 2 AM because the regulator does not care about your "real-time AI." They care about a reconciled number.
This is the reality that every "AI for Banking" startup ignores. And it is why, after a decade of pilots, demos, and proof-of-concepts, banking still does not have a production-grade AI architecture.
Not because the models aren't good enough. Because the architectures were built by people who never had to explain to a regulator why an LLM approved a mortgage.
The Problem Is Not the Data. It's the Permission Model.
I spent years writing SQL against Citi's core systems. I built reports for the mesa de dinero. I integrated Oracle with SQL Server with flat files from acquired banks. I know exactly where the data lives.
And I can tell you: the data is there.
The customer exists in KYC. The credit score exists in the risk system. The transaction history exists in the core. The AML flags exist in the compliance database. They are reconciled nightly. They are governed. They are auditable.
What does not exist is a way to let an AI consume that data without becoming a privileged user of it.
Every agent framework I have evaluated makes the same fatal assumption: that the bank is a greenfield SaaS platform where an orchestrator can own credentials, inject schemas into prompts, and let the LLM "figure out" which table to query. This is not architecture. This is a breach waiting for a CVE number.
In a bank, giving an agent a connection string to the credit database is not a technical decision. It is a career-ending decision.
What I Saw in Every Failed AI Pilot
At Bloomberg, I watched fintech after fintech pitch "AI-powered credit decisioning." The demos were beautiful. The models were impressive. The pilots died the same way every time:
- The agent needed data from three systems. So the integration team opened three connections.
- The agent needed context. So they embedded the full database schema into the system prompt.
- The prompt grew to 10,000 tokens. Each LLM call cost a dollar. At scale, the business case collapsed.
- The compliance team asked: "Who approved this access?" Nobody had an answer. The pilot was shelved.
The pattern was always the same. The model worked. The data was available. The architecture was the failure.
And the root cause was always the same: the AI was given the same access patterns as a human analyst, but without the same accountability.
A human analyst who queries the credit database leaves an audit trail. They have a user ID. Their query is logged. Their access is role-based. When an LLM agent does it through a connection string embedded in a Docker container, there is no user. There is no session. There is no trace that a regulator will accept.
IRC-A: Built from the Inside
I left Bloomberg knowing that banking would not adopt AI until someone built an architecture that spoke the language of the bank: segregation of duties, batch reconciliation, immutable audit trails, and the absolute certainty that no agent would ever hold a database credential.
IRC-A is that architecture. Not because it is clever. Because it is boring in the right ways.
The Core Insight: The Data Stays. The Access Changes.
IRC-A does not ask you to migrate your Oracle database. It does not ask you to replace your AS/400. It does not ask you to build a "unified customer view" that takes five years and fifty million dollars.
It asks you to do one thing: put an MCP server in front of each system, and never let the agent touch the system directly.
Here's how it works in practice:
Your CreditRiskMCP server runs in an isolated container. It has the Oracle driver. It has the read-only credentials. It knows the schema. It is the only thing that ever queries the credit database.
Your AMLMCP server runs in a different container. Different credentials. Different schema. Different channel.
The agent—stateless, credential-free, schema-free—sends a natural language intent to the BFA Gateway: "I need to evaluate credit risk for customer ID-882."
The Gateway performs a semantic vector search, finds the CreditRiskMCP, verifies that both the agent and the tool share the #credit-audit logical channel, and issues an Ephemeral Delegated Execution Token (DET).
This token is:
- Cryptographically signed by the Gateway.
- Time-bound (expires in minutes).
-
Parameter-locked (only
fetch_credit_score(customer_id="882")is allowed). - Auditable (every token issuance is logged with a trace ID).
The agent calls the MCP server directly. The MCP server validates the DET offline—no round-trip to the Gateway—and executes the query. It returns a sanitized JSON payload. The agent never saw a schema. Never held a credential. Never had the ability to do anything other than what was explicitly authorized.
When the regulator asks, "how did the AI approve this mortgage?" you don't reverse-engineer a prompt. You show them the DET, the channel membership, and the sanitized response. The audit trail is the architecture.
Why This Matters: The Trading Desk Test
I have a mental test for any AI architecture proposed for banking. I call it the Mesa de Dinero Test:
If this agent fails at 5:45 PM on a Friday, can the Trading Desk close its batch on time without it?
Most agent architectures fail this test. They are tightly coupled to the core. They run in the critical path. If they go down, the batch stops.
IRC-A passes because it is decoupled by design. The MCP servers are adapters, not replacements. The core systems keep running their batches. The agents consume the outputs when they need them. If the AI cluster goes down, the bank keeps operating exactly as it did before.
This is not a bug. This is the feature that makes a bank CIO sleep at night.
The Token Economics Are Real
Here is something I measured myself. A traditional agent framework carrying twelve tool schemas in its system prompt consumes between 4,000 and 8,000 tokens per call before it even starts reasoning. At scale—fraud detection, customer service, mortgage underwriting—that is not a cost. It is a budget fire.
In IRC-A, the agent carries zero schemas. It describes its intent in natural language (~50 tokens). The Gateway resolves the capability via vector search. The agent receives a single route and a DET.
The difference is not marginal. It is the difference between a viable AI operation and a pilot that gets killed in the Q3 budget review.
The Gap No One Is Talking About
Go to any AI conference. You will hear about agents, RAG, fine-tuning, and multimodal models. You will not hear a single talk about how to make an AI architecture auditable to a banking regulator.
This is the gap. This is why, after years of investment, banking AI is still 90% pilot and 10% production.
The banks that will win are not the ones with the biggest LLM budgets. They are the ones that solve the governance problem first. They are the ones that build—or adopt—an architecture where:
- Agents are stateless and credential-free.
- Data access is mediated, parameterized, and logged.
- Discovery is semantic, not hardcoded.
- Audit trails are generated by the protocol, not bolted on afterward.
IRC-A is my proposal for that architecture. It was not designed in a hackathon. It was designed in the space between a conciliation batch and a compliance report, by someone who knows that in banking, the most advanced model in the world is useless if it cannot prove why it made the decision it made.
Conclusion: The Architecture Banking Has Been Waiting For
Banks do not need another data lake. They do not need another "unified customer view." They do not need an AI platform that promises to replace their core.
They need an architecture that says: your systems are fine. Your data is fine. Let's just consume it safely.
IRC-A is that architecture. It is not a revolution. It is a secure access layer for a world that already works.
And maybe—just maybe—it is the first AI architecture that a bank can actually adopt without betting the institution on it.
Sandro Garcia is the creator of the IRC-A protocol and BFA-SDK. He spent 12 years as a tech lead at Citibank and 2 years at Bloomberg, building systems for conciliation, regulatory reporting, and trading operations before designing secure multi-agent architectures for regulated industries.
Top comments (0)