Table of Contents
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.
Request-Response Bank – fraud lifecycle
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.
Event-Driven Bank – fraud lifecycle
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. The notification service is listening. The loyalty engine is listening. The customer-360 store is listening. The AML monitor is listening. None of them is asking the core for permission. None of them 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.
You stop building point-to-point pipes every time something new is required. You start running an institution where information is already in motion, and new products are ways of listening to it.
Join Our Newsletter
Get exclusive insights on banking, fintech, regulatory updates and industry trends delivered to your inbox.
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. Every event needs an owner. Every schema needs a lifecycle. Every stream needs lineage that can be explained to a supervisor without a slide deck.
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.
The Choice Is Already Being Made
The banks that pull ahead in the next five years will not be the ones that process transactions the fastest. They will be the ones that trust their own event streams enough to build new products on them without asking permission from the core. The only real question is whether the path you are on was chosen deliberately, or one integration at a time.
Not Sure Which Path You Are On?
The Digital Fifth works with banks and NBFCs on enterprise architecture and integration strategy for real-time banking. We can help you figure out which path you are on and what to do about it.
