One AFC platform across every product

Transaction monitoring across Broker, Wealth, Credit and Banking. MVP and six-month delivery.

Edvin Mæhre · Product Manager, Anti Financial Crime

2SUMMARY

The new AFC platform at a glance

Six milestones across twenty-six weeks, drawn to scale A single time rail from week zero to week twenty-six. Six blocks sit on it at their true duration: discovery to week two, the client data aggregation layer to week ten, the loop to week fourteen, first restriction to week eighteen, real-time coverage to week twenty-four, and measure and decide to week twenty-six. The aggregation layer is the widest block, at eight of the twenty-six weeks. Go-live sits at week fourteen. 0210 141824 26 M0 M1 M2 M3 M4 M5 Discovery The aggregation layer The loop First restriction Real-time coverage Measure and decide First alerts in production · week 14
3THE PLATFORM · THE PROBLEM

The product line keeps growing. Monitoring is still written per product.

A layering sequence across four days and three product surfaces A client deposits ninety thousand euros into the settlement account, buys and sells an ETF in the broker, adds a second reference account in their own name and makes it primary, then withdraws eighty-eight thousand euros to that new account. Each product sees one ordinary event. The sequence exists only where the products are joined at the client. DAY 1DAY 2 DAY 3DAY 4 As each product sees it nothing here is unusual Banking & settlement a deposit and a payout Broker two ordinary trades Reference accounts a customer preference €90,000 in from account A €88,000 out to account B Buy ETF Sell ETF Account B added own name, verified B set as primary payouts now go here Joined at the client this is the alert Client 98% of the deposit round-tripped in four days, and the payout account changed mid-sequence
4THE PLATFORM · OUTCOMES AND ASSUMPTIONS

What success looks like

Better precision means fewer alerts for the same reports filed.

  • Technical
    • Precision per control and system-wide → analyst hours saved
    • Recall, proxied by third-party requests → cases we would otherwise miss
  • Business
    • Cycle time per alert → how fast a customer is released
    • Alerts per analyst per day → operations cost per client
    • Alerts per active client, falling → monitoring cost holds as we grow
  • Compliance: never sacrificed.

Assumptions and open questions

  1. Layering carries volume, credit fraud the loss, takeover the severity → first measurement window
  2. Device and IP data may not reach AFC usably → week-one discovery
  3. No front-end capacity here, so customer messaging is out → team composition at start
  4. Existing case management can be extended → build-versus-buy assessment

Open questions

  • Current alert volume
  • Operations headcount
  • Precision today
5THE PLATFORM · MVP SCOPE

The first release builds the client data aggregation layer every later control is built against

Sources feeding one client data aggregation layer, and the signals it makes visible Six data sources on the left feed one client data aggregation layer in the middle. Six signals emerge on the right that no single product line can see: round-trip velocity, traded volume over deposited volume, bulk liquidation followed by a reference-account change, loan drawdown followed by an outbound payment, a securities transfer out shortly after a deposit, and inflow inconsistent with the declared profile. Sources PRIORITY ORDER Client and profile 1 REAL TIME Transactions, all products 2 REAL TIME Device and session 3 REAL TIME · MAY NOT REACH AFC USABLY Reference-account events 4 REAL TIME Loan application and drawdown 5 REAL TIME · CREDIT FRAUD WAITS WITHOUT IT Trades, orders, portfolio 6 REAL TIME Real time by default. Batch if necessary. The aggregation layer Client data aggregation layer ENTITIES client · account reference account transaction · trade · loan device · alert · case One latency contract per source Signals that become visible at client level Round-trip velocity: deposit → trade → withdrawal Traded volume over deposited volume Bulk liquidation, then a reference-account change Loan drawdown, then outbound in a short window Securities transfer out shortly after a deposit Inflow inconsistent with the declared profile
6THE PLATFORM · MVP SCOPE

Three typologies, three product surfaces. Everything else sits in the aggregation layer and waits for a control.

The financial-crime taxonomy, and the one typology each branch puts in the MVP Financial crime branches into money laundering, first-party fraud and third-party fraud. Each branch contributes one typology to the MVP: first-party layering, which carries volume and fires on bank and settlement; credit and loan fraud, which carries our own money and fires on credit and loans; and account takeover, which carries severity and fires on securities transfer in and out. Under each named typology, a dotted stub marks the further typologies that wait in the aggregation layer for a control. Crime type The typology in the MVP The risk it carries, and where it fires Financial crime Money laundering First-party layering VOLUME BANK AND SETTLEMENT First-party fraud Credit and loan fraud OUR OWN MONEY CREDIT AND LOANS Third-party fraud Account takeover SEVERITY SECURITIES TRANSFER IN AND OUT EACH CRIME TYPE HOLDS FURTHER TYPOLOGIES. THEY WAIT IN THE AGGREGATION LAYER FOR A CONTROL.
7THE PLATFORM · THE HOLISTIC VIEW

Signals that become visible at client level

Sources feeding one client data aggregation layer, and the signals it makes visible Six data sources on the left feed one client data aggregation layer in the middle. Six signals emerge on the right that no single product line can see: round-trip velocity, traded volume over deposited volume, bulk liquidation followed by a reference-account change, loan drawdown followed by an outbound payment, a securities transfer out shortly after a deposit, and inflow inconsistent with the declared profile. Sources PRIORITY ORDER Client and profile 1 REAL TIME Transactions, all products 2 REAL TIME Device and session 3 REAL TIME · MAY NOT REACH AFC USABLY Reference-account events 4 REAL TIME Loan application and drawdown 5 REAL TIME · CREDIT FRAUD WAITS WITHOUT IT Trades, orders, portfolio 6 REAL TIME Real time by default. Batch if necessary. The aggregation layer Client data aggregation layer ENTITIES client · account reference account transaction · trade · loan device · alert · case One latency contract per source Signals that become visible at client level Round-trip velocity: deposit → trade → withdrawal Traded volume over deposited volume Bulk liquidation, then a reference-account change Loan drawdown, then outbound in a short window Securities transfer out shortly after a deposit Inflow inconsistent with the declared profile
8THE PLATFORM · RULES AND MODELS

The more critical the risk, the stronger the mitigation

  • Anything that blocks a customer must be a rule. A rule has a known false-positive cost and a policy to point at.
    • Layering → the client, overnight, no restriction
    • Credit fraud → the outgoing payment, real time, block and freeze
    • Account takeover → the outgoing transaction, real time, freeze
  • Each control launches with a minimum precision. We set it with Compliance.

Models come after labels

  • They arrive in three steps: general financial-crime model → crime type → sub-type
    • Each step needs more labelled outcomes
    • Order follows labels held and risk urgency
  • Baselines per client: €10,000 is enormous for one, routine for another
9THE PLATFORM · EXPLAINABILITY

Three audiences need three different explanations

  • Analyst: what fired, the values, the threshold crossed, how often this control has been right
  • Auditor: the policy implemented, and the rule version pinned to the alert
  • Customer: expectation and timeline. Tipping-off law limits the rest.
  • Benchmark: measured against what a typical alert gives the analyst today
ALERT 48213
Client C-90412  ·  raised 09:14 CET
Rule LAY-03  version 2.4
Financial crime  ›  money laundering  ›  first-party layering
What fired
Outgoing transfer of €100,000 to an account in Switzerland
This control treats transfers above €50,000 to Switzerland as risky.
This client sent €100,000.
31%
of alerts from this control were confirmed
true positives over the last 90 days
The sequence behind it
Day 1  €90,000 in from reference account A
Day 2  ETF bought, then sold — net −€500
Day 3  Reference account B added, then set as primary
Day 4  €88,000 out to reference account B
True positive False positive Send a request for information Escalate
10THE PLATFORM · DATA AND DEPENDENCIES

Person first, then money, then device, then the rest

Sources feeding one client data aggregation layer, and the signals it makes visible Six data sources on the left feed one client data aggregation layer in the middle. Six signals emerge on the right that no single product line can see: round-trip velocity, traded volume over deposited volume, bulk liquidation followed by a reference-account change, loan drawdown followed by an outbound payment, a securities transfer out shortly after a deposit, and inflow inconsistent with the declared profile. Sources PRIORITY ORDER Client and profile 1 REAL TIME Transactions, all products 2 REAL TIME Device and session 3 REAL TIME · MAY NOT REACH AFC USABLY Reference-account events 4 REAL TIME Loan application and drawdown 5 REAL TIME · CREDIT FRAUD WAITS WITHOUT IT Trades, orders, portfolio 6 REAL TIME Real time by default. Batch if necessary. The aggregation layer Client data aggregation layer ENTITIES client · account reference account transaction · trade · loan device · alert · case One latency contract per source Signals that become visible at client level Round-trip velocity: deposit → trade → withdrawal Traded volume over deposited volume Bulk liquidation, then a reference-account change Loan drawdown, then outbound in a short window Securities transfer out shortly after a deposit Inflow inconsistent with the declared profile
11THE PLATFORM · CASE HANDLING

An alert moves between three parties until somebody closes it

The case that holds the alerts, and one alert moving between second line, first line and the customer Case 1182 is drawn at the top as a container. It opens at the first alert and holds one bar per alert. Below it are three lanes: second line, first line, and the customer. The alert is raised and queued in first line, moves down to the customer when information is requested, returns to first line with the reply, then moves up to second line when it is escalated and closed there. A second alert, a credit fraud alert, is raised later in first line and joins the same open case, which moves the case to the fraud team. CASE 1182  ·  OPENED AT THE FIRST ALERT 2 ALERTS ALERT 48213  ·  FIRST-PARTY LAYERING ALERT 48219  ·  CREDIT FRAUD Second line First line Customer Raised Queued Information requested Reply Escalated Closed Second alert raised
12THE PLATFORM · FEEDBACK AND RISKS

Every closed alert leaves a typed label behind, in our own store

  • IDs that join it up: client, entity, alert, case, transaction
  • Each control fires on a named entity. Takeover is caught at the transaction.
  • Our backend, whichever vendor raised it. The engine can then be replaced.
  • Feeds precision per control, and every model step on slide 8
The three levels every closed alert is labelled against Level one is financial crime. Level two is money laundering, first-party fraud or third-party fraud. Level three is the typology: first-party layering, credit and loan fraud, or account takeover. Every label carries three levels Financial crime Money laundering First-party layering First-party fraud Credit and loan fraud Third-party fraud Account takeover

Three ways this goes wrong, and what we do in week one

  • Volume exceeds what operations can work. A backlog is a regulatory finding.
    • Back-test on production data before go-live
  • Critical data missing. Device and IP is the canonical case.
    • Decide in week one
  • Labels captured badly, and the model track dies quietly.
    • Both lines QA the typology. Track label quality.
13DELIVERY · ROLLOUT

Build the feed. Rent the engine. Specify the rules. Assess the workflow.

The four stages every control moves through, ordered by who sees the alert Four equal bars run left to right. Stage one is back-test, on historical data. Stage two is shadow, on live data. Stage three sends alerts to the analyst queue, on live data. Stage four applies a restriction, on live data. The first three bars deepen through blue; the fourth is red, because it is the only stage the customer feels. Underneath, three brackets group the stages by exposure: stages one and two are seen by nobody, stage three is seen by an analyst, stage four is felt by the customer. A return arrow from stage four to stage three shows that a misbehaving control moves down a stage and keeps its signal. A closing note reads that stages one and two are a procurement requirement. 1 · Back-test 2 · Shadow 3 · Alerts to the queue 4 · Restriction applied historical data live data live data live data NOBODY SEES IT AN ANALYST SEES IT THE CUSTOMER FEELS IT A MISBEHAVING CONTROL MOVES DOWN A STAGE, KEEPING THE SIGNAL Stages 1 and 2 are a procurement requirement. A rule builder that cannot do both fails the vendor evaluation.
14DELIVERY · TIMELINE

Six milestones. Each one ends when its condition is met.

Six milestones over twenty-six weeks, and the three controls climbing the four stages beneath them One time axis runs from week zero to week twenty-six. Six milestone bars sit on it at their true duration: discovery ends at week two, the record at week ten, the loop at week fourteen, first restriction at week eighteen, real-time coverage at week twenty-four, and measure and decide at week twenty-six. M2 and M4 are marked as carrying a dependency, on the case-management decision and on device and IP data. Below the milestones, three control lanes climb the four rollout stages at their real durations: first-party layering reaches stage three at week fourteen and goes no higher, credit and loan fraud reaches stage four at week eighteen, and account takeover reaches stage four at week twenty-four. 0 2 10 14 18 24 26 M0 Discovery M1 The record M2 The loop WAITS ON THE BUILD-OR-BUY DECISION M3 First restriction M4 Real-time coverage WAITS ON DEVICE AND IP DATA M5 Measure and decide Controls, by stage First-party layering Credit and loan fraud Account takeover 1 · Back-test 2 · Shadow 3 · Alerts to the queue 4 · Restriction applied The layering control never reaches stage 4. Stage boundaries follow the milestone dates.
15DELIVERY · TRADE-OFFS

Spend the ambition on the data layer. Buy speed wherever a decision is cheap to reverse.

  • The data layer cannot be reversed. A rebuild takes the label history with it. Expect to spend real time here.
  • De-risk while building: reconcile each feed on landing, replay an investigated case before building on top.
  • Latency is the second cost. No control may delay a pay-in or a pay-out.
  • Analyst headcount limits control strength. Too much volume, and we cut typology scope and hold precision.
The platform drawn as a house, where height means how cheaply a decision can be reversed The client data aggregation layer is the foundation, drawn widest and deepest, because a rebuild takes the label history with it. Above it sit two courses of bricks. The lower course holds the monitoring engine, which can be swapped because we own the data, and case management, which is settled as a build-or-buy decision. The upper course holds machine learning, which waits for labels, customer-facing explainability, which needs people, and absorbed products, which need a control written. A roof closes the house. CHEAPER TO REVERSE Machine learning reverse it by waiting for the labels Customer-facing reverse it by adding people Absorbed products reverse it by writing a control The monitoring engine swap it, because we own the data underneath it Case management build or buy, settled by the week-one assessment The client data aggregation layer A rebuild takes the label history with it Our ambition scales with irreversibility.
16DELIVERY · VALIDATION

Before go-live

Prove everything the customer can feel and everything that cannot be undone

  • Every feed reconciled against its source system
  • Volume fits the queue, back-tested against the agreed ceiling
  • The loop closes: one alert created, queued, worked, closed, typed, stored
  • Restrictions can be lifted. Most teams miss this, and only the customer feels it.
  • The explanation renders. An analyst works shadow alerts and says why each fired.

Precision stays an estimate until go-live. Plan capacity conservatively.

After go-live

The measures from slide 4 become real numbers

  • Real precision per control, from closed cases
  • The real incidence mix. If takeover is common, it moves up the build order.
  • Threshold tuning. First to need changing, cheapest to change.
  • Model feasibility answered. If labels fall short, fixing label capture is the next release.

Improvement comes from tuning, compounding labels, and a regular threat-modelling pass.

17DELIVERY · CADENCE AND ESCALATIONS

Two forums, one check

Every meeting ends with a decision

  • Steer on milestones. The iteration rhythm belongs to the engineering manager.
  • AFC control forum, monthly
    • Scorecard: volume, precision, cycle time, label quality per control
    • Quarterly: coverage map and appetite
  • Milestone review, when a milestone closes
    • One-pager: exit conditions, status, decision asked for
  • New-product check at every launch: what value movement, which typology, covered or accepted

No decision due, no meeting.

Three things go to somebody else in week one

Each with a recommendation and a date

  • Case management: a named owner and a decision date. A conversation now, a milestone in month four.
  • Device and IP data: answer it, and start the work if the answer is no.
  • Vendor walkthrough before signature. A small ask early, an impossible one late.

Escalate with a recommendation. An open problem handed over moves sideways.