Banks do not have beautiful APIs. Banks have Finacle, Flexcube, and BaNCS. They have COBOL batch jobs on mainframes that predate the word "endpoint," EOD extracts in fixed-width EBCDIC dropped onto SFTP servers, and an ISO 8583 switch carrying every transaction in a format designed in 1987. The median core banking system in India is old enough.
Governance without the data is theatre
To govern AI in a bank you need to see three streams, continuously:
1. Sanctioned AI traffic. Every prompt, response, model version, and downstream action from the bank's own AI systems. This is the solved part: put a gateway in the request path, issue virtual keys, force the funnel at the network layer. A dozen products do this. It is table stakes.
2. Third-party and shadow AI. Copilot inside M365, Einstein inside Salesforce, employees pasting customer data into consumer chatbots. Vendor audit APIs, CASB events, DNS logs. Harder, still tractable.
3. The operational context from core systems. This is the stream everyone skips, and it's the one that makes governance real. An AI decision is only auditable against what the bank's systems of record actually said. Did the model's credit decision match the account's true classification in the CBS? Did the collections agent's promise line up with the actual DPD bucket? Is the AI's output drifting against the transaction reality in the switch? You cannot answer any of this from the gateway. The answers live in the core, and the core speaks EBCDIC.
The engineering nobody demos
Extracting from a core banking system has one design law: never touch the application. The change-control cycle on a CBS is measured in quarters, and no bank will modify a system that settles money so a governance vendor can have telemetry. You extract from around it. There are a handful of ways in. Some ride the database layer, some ride the messaging rails banks already run, some work off the extracts these systems have been emitting for decades. Each has a different latency, a different risk profile, and a different reception from a bank's security team. Knowing which door to use for which system, at which bank, on which version, is the actual expertise, and it doesn't transfer from a blog post. It transfers from having done it. What separates a connector product from a consulting one-off is discipline, not cleverness:
- Everything normalizes to one schema. Governance logic gets written once, against a canonical event, never against a source system. Sources are messy; the schema is not.
- Every release is tested against reality. The same core system behaves differently across banks, versions, and patch histories. That knowledge has to accumulate somewhere permanent, in a form that gates every release. Ours does.
- Read-only, one-way, agentless, self-auditing. Nothing installed on legacy hosts, nothing written back, and the connector logs its own access, because a governance platform with unauditable collectors is a punchline waiting for an inspection.
- The bank's data stays in the bank's perimeter. In India. This one decision is the difference between a 3-month and an 18-month procurement cycle.
None of this demos well. All of it is the product.
Why nobody builds it
The economics repel exactly the companies you'd expect to solve this.
A venture-backed governance startup optimizes for logos and demo velocity. The Finacle connector offers neither: it is months of grinding through file formats and version quirks, per system, per bank, and it produces no screenshot for the pitch deck. The big consulting firms will happily build it for you, once, at day rates, as a one-off that rots the moment the CBS gets patched. And the model labs are busy with alignment, which is their problem to solve; containment and evidence are yours, and those run on data plumbing.
So the market has converged on a comfortable fiction: governance platforms that assume the data layer, sold to banks that don't have it. Everyone demos the dashboard. Nobody mentions that the dashboard is empty until someone writes the connector. The irony is that this grind is precisely where the defensibility lives. A policy engine can be rebuilt in a quarter. A tested connector library across core banking systems, versions, and deployment quirks compounds with every bank it touches, and it cannot be shortcut, because the only way to learn that one bank's EOD extract swaps two fields after a 2019 patch is to have parsed it. In AI governance for banking, the moat is not the AI. The moat is the parser.
How Enterprise AIMS approaches this
We built Enterprise AIMS around one position: govern the AI at the gateway, anchor every judgment in the bank's systems of record. The engagement model follows from it.
Assessment before deployment. We start by mapping the institution's AI estate against its systems of record: what AI is running, sanctioned or not, and where the evidence gaps sit against regulatory expectations. The findings document is the bank's to keep, whether or not it proceeds with us.
Phased rollout, visibility first. The gateway goes live in weeks, capturing sanctioned AI usage 24/7 with attribution to team and application. Third-party collectors follow. Core system connectivity rolls out system by system, drawing on our existing connector library rather than building from zero.
Architecture built to be examined. Read-only and agentless. Nothing installed on legacy hosts, nothing written back. One auditable schema, data inside the bank's perimeter and inside India, and collectors that log their own access. We expect to sit inside the scope of the bank's inspections, not outside them. The result answers the question examiners actually ask. Not "what did the AI say," but "what did the AI say, what did the system of record say, and did they agree." One question for any vendor whose demonstration begins at the dashboard: where does the data come from, and from which of our systems, specifically? We are comfortable being asked. It is where our engagement begins.
