Enterprise Architecture · Real-Time Banking

Real-Time Banking, Running on Batch Rails.

Why three unrelated teams are unhappy for the same reason.

The Digital Fifth  ·  Enterprise Architecture  ·  6 min read

Ask the fraud head, the product head, and the CISO of a bank what is slowing them down. You will get three different answers. Underneath, it is usually the same one.

The fraud head will say her team catches things after the money has moved. The product head will say his team spends six months on integrations that were meant to take six weeks. The CISO will say she cannot get a clean, real-time view of what is happening across the estate.

Three complaints, one architecture. The bank is running a real-time business on request-response plumbing.

Watch One Transaction Move Through Two Different Banks

In the first bank, the request arrives, the core authorises it, the transaction settles, and a batch job flags it as suspicious some minutes or hours later. By then the customer has moved on and, occasionally, so has the money. The fraud analyst opens a ticket. The customer gets a call the next morning. The regulator gets a report at month-end.

In the second bank, the same transaction publishes an event the moment it is initiated. The fraud engine listens, can score it in milliseconds in well-architected event pipelines, and either lets it through, holds it, or triggers a step-up. The customer gets a notification before their phone is back in their pocket. The analytics layer sees the pattern within seconds.

The difference is not the fraud model. Both banks may be running similar rules and similar scoring. The difference is when the fraud engine gets to see the event. In the first bank, it sees it after the fact. In the second, it sees it at the moment it matters. Everything else event-driven architecture enables is a variation on this pattern.

It Is Not Speed. It Is Simultaneity.

The obvious reading of the fraud example is that events make things faster. That is the least interesting part.

The more interesting part is that in the second bank, the fraud engine is not the only thing listening. None of these is asking the core for permission. None is waiting on the others.

This changes what the bank can build. A new product team does not negotiate access to the core; they subscribe to events that already exist. A fintech partner does not need a bespoke integration; they plug into the event layer and consume what they need. A compliance team does not reconstruct evidence at month-end; the lineage is already there, event by event, with timestamps.

The Governance Bill Nobody Signs For

The technology is the easy part. Kafka, Pulsar, event meshes — the tooling is mature and well documented. The hard part is that once systems stop asking and start listening, discipline moves from central applications to the event layer itself.

Without this, banks end up with the worst of both worlds: a distributed architecture with centralised confusion. Streams no one owns. Schemas that break silently. Fraud alerts that arrive twice or not at all. A CISO who cannot answer what an event did on its way through the estate.

RBI operational-resilience guidance does not prescribe event architectures, but it emphasises outcomes — traceability, ownership and recoverability — that well-governed event systems can deliver. Banks that build event streams without this discipline are not just taking a technology risk. They are building a compliance surface they cannot see.

Every Indian Bank Is Already Picking One of Three Paths

Whether they have named it or not.

Many Indian banks have effectively landed on Path 2 in practice. Each integration made sense on its own. Together, they have produced an event layer with no owner, no schema discipline, and no lineage. The more thoughtful banks are moving to Path 3 while the core work continues in parallel — which is uncomfortable, but honest.