Integrated Risk Analytics Platform

Risk and compliance monitoring in a bank is not one system. Separate tools watch different platforms, systems and channels, each with its own thresholds, its own queue and its own screens. Each is reasonable on its own.

The correlation happens in the supervisor’s head. To work out whether an alert in one place relates to activity in another, a supervisor today opens several applications, looks up the same person or activity in each, and pieces the trace together by hand. It is slow, hard to repeat and depends on knowing where to look. From first alert to a reported finding, that can take around 30 days. A pattern that only shows across two systems is easy to miss, and a benign alert costs as much time to close as a serious one.

The platform does that legwork. It assembles the trace across systems into a single case, with its evidence, in one place. The supervisor starts from the full picture instead of building it.

The hard part is correlation, and it has three layers.

Many sources, one trace. Activity arrives from different platforms, systems and channels, each with its own format and its own idea of what an event is. Before anything can be linked, it has to be brought into a common shape without losing what each source meant.

Linking by meaning, not just by matching fields. Two events relate because of what they are, not only because they share an identifier. Correlation runs on the schema and on business definitions: what counts as the same activity, which events belong to the same chain, and what time window makes them relevant to each other.

Reading intent from precursors. A single event rarely shows intent. The sequence leading up to it often does. The engine checks each trace against regulatory and compliance obligations, looking for the precursors that separate an innocent one-off from a deliberate act.

All of this has to happen in minutes, and the supervisor still makes the decision. An LLM that writes one confident narrative invites the reader to agree with it, so the interface informs the judgement without nudging it.

Still a proof of concept, so this is the shape rather than the build. The ingestion side is owned separately. I own the correlation engine and the supervisor interface.

Ingestion brings activity from each platform, system and channel into a common, event-driven form, then hands each event over to the agents.

Correlation is done by domain agents. Each agent specialises in one domain and knows how malicious activity is defined there: the regulatory and compliance definitions, and the precursors that usually come first. Every agent sees every event, as it arrives. Each one tries to correlate the new event with past events into a series that matters in its own domain. The same event can be innocent to one agent and a precursor to another.

Each agent works the same way, and no single step is trusted on its own.

1. Link. It links events using the schema and business definitions, states why they relate, and cites the fields it relied on. Links below a confidence threshold are shown as “possibly related”, not merged.

2. Explain each event innocently first. Most events, taken one at a time, have an ordinary reason behind them.

3. Judge the series. It reviews the whole sequence against its domain’s definition: does it still read as an innocent one-off, or does it now meet the definition of a deliberate act? The judgement cites the events it rests on.

The agents’ judgements are combined into the AI recommendation for the case. Each agent is evaluated against past, already-decided cases in its domain, rather than judged on how plausible it sounds.

The supervisor workspace is the front door: one central place where a supervisor sees the cases the platform has assembled and acts on them, instead of visiting each system in turn. It is surfaced inside the division’s existing application shell, so supervisors reach it where they already work.

An AI recommendation per case, built from the domain agents’ judgements, with the reasoning behind it.

Every detail behind that recommendation, one click away. The timeline of events across platforms, systems and channels, each event’s innocent explanation, the precursors flagged and the case assessment. Nothing is hidden behind the recommendation, so the supervisor can see why it was made and disagree with it.

What would make the judgement firmer. Where confidence is low, the workspace shows which factors or details are missing. The supervisor can provide them, and every agent then re-evaluates the whole case with the new information.

Everything on record. The supervisor’s decision, their reasons and any information they add are recorded alongside what the system showed them. That makes every outcome transparent, reportable and auditable.

The work at this stage is as much about value as engineering. We’re finding out which recommendations supervisors actually trust before building for scale.

Prove the value before the scale. Cutting 30 days to five minutes is the claim that matters, and it has to hold on real cases before volume is worth engineering for.

How you ask changes what you get. A model asked to find wrongdoing finds some. A model asked to explain events innocently, and then to test whether that explanation survives the series, is far more measured.

A recommendation is only as good as its reasons. Supervisors trust what they can inspect and push back on, so every judgement shows its evidence and accepts new information.

A lean team runs on short iterations. Nothing about this proof of concept holds still. The data changes, our understanding of it deepens, its quality improves, and what supervisors want to see keeps shifting. Small iterations let us absorb each change as it lands instead of planning around a picture that’s already out of date.