What an early warning system actually has to do
An early warning system (EWS) is the part of a bank's risk stack that is supposed to notice a borrower going wrong before the account becomes a non-performing asset. In practice that is four jobs that never stop: ingest borrower data from several sources, score it against rules and models, put the resulting signals in front of the right officer, and record what that officer decided. Let any one of them run slow and the system produces a report on who needed a call last quarter instead of who needs one today.
We have built early warning systems on Spring Boot twice: a predictive credit-risk EWS for CareEdge, which watches borrower portfolios across several banks, and the migration of Bank of Baroda's EWS after its merger with Vijaya Bank and Dena Bank. This article is the architecture those two projects converged on, and the failure modes it is shaped to avoid. It is written for the engineering and risk teams scoping one; for how we run such a project end to end, see our Spring Boot development page.
The regulatory backdrop sets the non-negotiables. RBI's Master Directions on Fraud Risk Management (2024) expect banks to operate an EWS framework, red-flag accounts on defined signals and keep a trail of who acted on what. So an EWS is never just analytics. It is analytics plus workflow plus audit, and the architecture has to carry all three from day one.
Why Spring Boot for the backend
Three reasons, in the order clients usually raise them.
It fits the estate. Indian banks, and the analytics firms that serve them, run on Java, Oracle and Tomcat, with security and operations teams who know how to run them. Both of our EWS builds are Java 11 Spring Boot services on Tomcat against Oracle DB, with source on GitHub — nothing the bank's operations team had to learn from scratch. A platform that needs a new runtime, a new database and a new on-call rota is a harder sell than a better rule engine, and it should be.
The parts you need are first-party. Scheduled and batch ingestion, transactional persistence, REST with validation, method-level security, health endpoints and metrics are all in the Spring portfolio (the Spring Boot reference covers the lot), and they compose without glue code. For a system a regulator may audit, building on well-known components rather than a bespoke framework is itself a control.
Services scale independently. This is the reason that decided the Bank of Baroda migration. Their EWS had been built for one bank's data. After the mergers it had to ingest the merged entities' systems as well, and the legacy monolithic architecture could not support that scale. Decomposing it into Spring Boot microservices let the ingestion pipelines scale on their own while the analytics and the approval workflow stayed put — and the system went on to handle three times the data volume.
The reference architecture
We split an early warning system into five services behind one REST contract. The names vary by client; the boundaries do not.
Ingestion
One pipeline per class of source, not one per bank. For CareEdge the sources were financial statements, transaction history and external bureau data, arriving from five core banking systems over secure REST APIs. For Bank of Baroda they were the merged entities' systems, each with its own formats and cut-off times. Ingestion normalises all of it into one borrower model and makes every load idempotent: re-running yesterday's file has to produce exactly the same records, or reconciliation becomes guesswork. This is also where "without legacy disruption" is won or lost — the integration reads from the core banking systems through their APIs and never writes back into them.
Rules and scoring
The rule engine evaluates each borrower against configurable thresholds and, where the client has the data for it, predictive modules that score the trend rather than the snapshot. It writes signals, not screens: a signal carries the borrower, the rule and rule version that fired, the values that tripped it, and a severity. Everything downstream is built from that record.
Alerting
Alerting turns signals into a prioritised queue for the officers responsible for that borrower, and pushes it to the dashboard as it happens. Real time here means "before the officer's next look", not sub-second — but it is not a nightly batch either, which is what most legacy EWS reporting amounts to.
Workflow
Every action on an alert — acknowledge, escalate, red-flag, close — runs through a maker-checker state machine that lives in its own service, with its own append-only decision log. More on this below, because it is the part that is most often bolted on late and most painful when it is.
Dashboard and reporting API
A single REST API serves the Angular front end (Angular 14 as a standalone single-page application for CareEdge; Angular portlets inside the bank's portal for Bank of Baroda) and the reporting exports. The same contract the bank integrations use is the one the dashboard consumes, so there is one definition of data in and signals out.
A rules engine that risk officers own
The single design decision with the largest payoff is to treat rules as data, not code. In CareEdge's EWS the engine exposes its thresholds to non-technical risk officers, so the people who understand credit adjust the signals themselves, without a release. That removed the engineering team from the loop for the changes that happen most often — a sector-specific tightening after a bad quarter, a threshold that is firing too much on one bank's book — and it is a large part of why the real-time alerts cut NPA escalation response time by 60%.
Making that safe takes a few things we now consider standard. Rules are versioned and effective-dated, so a change can be scheduled and, if needed, reversed. Every alert stores the rule version that produced it, which is what lets you answer an auditor's "why did this account flag in March?" a year later. And a threshold change should be dry-run against the previous day's data before it goes live, so an officer can see how many accounts a new value would flag before committing to it.
Maker-checker is an architecture decision, not a screen
Regulation asks for a specific shape of control: a risk action is made by one officer and approved by another, at more than one level for the actions that matter, and every step is recorded. For Bank of Baroda, new regulatory requirements mandated exactly this — enhanced audit trails and maker-checker workflows — and we built a multi-level maker-checker approval workflow with RBI compliance modules into the migrated platform.
The mistake we see in legacy systems is implementing maker-checker in the user interface: a second confirmation dialog, a role check on a button. Then an integration or an admin script bypasses it and the audit trail has holes. In our architecture the workflow service is the only thing that can change an alert's state, the permission check is enforced in the service with Spring Security rather than in the screen, and the decision log is append-only. A dashboard, a report export and a bank-side integration all go through the same door.
Alerts that arrive as a queue, not a batch
The number the business notices first is review time. On Bank of Baroda's EWS, real-time financial risk alert dashboards reduced review cycles from two days to four hours. The change is not only that alerts arrive sooner; it is that the officer starts from a prioritised queue instead of a spreadsheet of everything, and that each item already carries the evidence that produced it.
Keeping that dashboard fast at volume is a data-modelling job. CareEdge's platform processes 100,000+ borrower records a day with sub-three-second query response, and it manages that because the dashboard never runs the scoring query. Scoring writes signals; the dashboard reads a model built for reading — pre-aggregated counts per officer, per sector and per severity, with pagination on everything. Separating the two is also what lets ingestion and scoring scale up without slowing the screens the officers are looking at.
Migrating without losing a record
A new EWS usually replaces an old one, and the old one holds the history a regulator will ask about. Bank of Baroda's migration was a complete technology migration — monolith to Spring Boot microservices, new front end, three banks' worth of data — and it was delivered with zero data loss and 100% data integrity maintained. That was planned, not hoped for.
The plan we use has four parts. Reconcile by counts and checksums per table and per source entity, before and after every load, with the differences explained in writing. Run the new platform in parallel on live data before cut-over, so its signals can be compared with the old system's on the same day's book. Rehearse the cut-over, including the rollback, on production-shaped data. And have the bank's own team sign off the reconciliation reports — the migration is not done when the engineers say so.
When the portal already exists: Spring Boot behind Liferay
Not every EWS is a standalone application. Bank of Baroda's runs inside the bank's Liferay DXP 7.4 estate: the portal supplies authentication, roles and navigation, the risk officers' screens are Angular portlets, and the Spring Boot services sit behind them. The front end is modern without leaving the DXP the bank already operates, which is the pattern we favour for banking platforms that have a portal and want to modernise what sits behind it.
The same shape scales up to a regulator. The EWS-Plus platform for the Royal Monetary Authority of Bhutan monitors the whole national banking sector for fraud indicators and instability signals; there Liferay carries more of the load — REST service modules for ingestion, a multi-level Kaleo workflow for maker-checker review, Elasticsearch for real-time search and alerting. Whether the services are Spring Boot or Liferay modules, the five boundaries above are the same. If you are starting from a portal, our Liferay DXP team scopes that side of the build.
What the two builds delivered
- Bank of Baroda: the migrated EWS scaled to 3x data volume after the merger; the maker-checker workflow meets RBI requirements; alert review cycles fell from 2 days to 4 hours; the migration completed with zero data loss.
- CareEdge: NPA escalation response time reduced by 60%; risk officers manage thresholds independently; five core banking systems integrated over secure REST APIs without disrupting them; 100,000+ borrower records a day at sub-3-second query response.
Scoping your own EWS
The questions we ask in the first week decide most of the architecture: which sources feed the system and what their cut-off times are; who owns the rules and how often they change; how many approval levels the bank's policy requires; how long decisions must be retained; whether the screens live in an existing portal or stand alone; and how much history has to migrate. From there the project follows the same path as any Spring Boot backend we build — an architecture review of the Java version, Spring generation, data stores and deployment path; an OpenAPI contract frozen before code; delivery one bounded context at a time with tests, migrations and observability; a hardening pass covering Spring Security, dependency scanning and load tests on production-shaped data; then CI/CD, runbooks and dashboards handed to your team.
If you are planning an early warning system, or replacing one that was built for a smaller bank than you are now, talk to us — we are happy to walk through either of these builds in more detail than a case study allows.
