Written by: Jakub Pietroszek, Partnership Manager, Digital Colliers
Interpol's HAECHI VI operation wrapped in July 2026 with 5,811 arrests and $293M seized across 97 countries. The rings they broke up did not care whether your victim opened a current account, a card, a loan, or a wallet. They exploited the seams between those products. Most mid-market banks still triage fraud one product at a time, on data that lands overnight. That gap is the whole story.
The product-by-product trap
If you sit in a fraud ops seat at a mid-market bank, you already know the shape of this. Card fraud sits in one tool. ACH and wire sit in another. Onboarding and KYC sit in a third. Each has its own analyst queue, its own case format, its own rules author. When a mule ring hits three of your products in the same week using overlapping devices, the alerts land in three different queues and nobody stitches them until someone files a SAR.
The cost of that fragmentation shows up in the false positive rate. Industry benchmarks put AML transaction-monitoring false positives at 85 to 95 percent at typical mid-market banks. That is not a modelling problem alone. It is a data problem. Rules fire on thin, single-product context because that is all the analyst sees at the moment of decision.
Why the nightly warehouse cannot save you
The standard answer is "we already have a data warehouse, everything lands in it." That is fine for reporting. It is not fine for fraud ops, for three reasons.
- Latency. A card auth decision has roughly 200 to 500 milliseconds. An ACH hold decision has minutes. A nightly ETL job cannot see either.
- Grain. Warehouses are shaped for accounting periods and product hierarchies. Fraud needs the entity as the grain, not the account.
- Joinability. If your card table and your wire table do not share a stable customer or device key at write time, no amount of downstream SQL will invent one.
DORA has been in force across the EU since 17 January 2025 and it puts operational resilience on the board's plate. "We batch overnight" is a hard answer to defend when the regulator asks how you would spot a coordinated attack across payment rails in real time.
The minimum viable entity layer
Cross-product entity resolution sounds heavy. In practice, the operators shipping this in 2026 tend to start with a narrow, boring foundation. Not a rebuild. A layer.
The minimum join keys most teams need:
- A stable internal party ID that survives product boundaries
- A device fingerprint hash written on every session, not just logins
- A normalised counterparty key for outbound payments, including IBAN, sort code plus account, and wallet address forms
- A shared event timestamp in UTC with sub-second precision
- A hashed identity bundle for KYC linkage without moving PII around
That is it for the first pass. Five keys, written at source, streamed into an entity store with sub-minute freshness. Rules and models query the entity, not the product table.
A worked example
Picture a mule network. Monday, they open six accounts through your mobile onboarding flow, all passing KYC individually. Tuesday, four of those accounts receive small card refunds from a merchant you also acquire. Wednesday, the funds consolidate through internal transfers into two of the six. Thursday morning, both push out via SEPA Instant to a payment institution abroad.
With product-siloed data and a nightly warehouse, each step looks clean in isolation. Onboarding sees six approvals. Acquiring sees six low-value refunds. Payments sees two outbound transfers under threshold. The pattern only appears on Friday, when someone runs a weekly report.
With an entity layer, the device fingerprint from onboarding links all six parties on Monday. The refund pattern on Tuesday raises the entity's risk score. The Wednesday consolidation trips a velocity rule at the entity grain. Thursday's outbound is held for review before it settles. Same rules engine. Different data shape.
What tends to go wrong
Around 95 percent of enterprise AI projects fail to reach production or ROI, and fraud modernisation projects fit the pattern. The failure mode is almost always the same: teams buy a model or a platform before fixing the data shape underneath it.
A few things worth watching if you are scoping this work:
- Automated credit and risk decisioning already carries GDPR exposure under the SCHUFA ruling from December 2023. Entity-level scoring inherits that exposure. Get your DPO in the room early.
- EU AI Act high-risk obligations apply from 2 December 2027. Fraud and creditworthiness systems sit inside that scope. The data lineage you build now becomes the audit trail you show later.
- Do not start with the model. Start with the five join keys and the streaming path. The model is the last mile, not the first.
The Interpol sweep is a useful mirror. The people attacking your bank are already operating cross-product and in real time. The question is how long your data model stays in yesterday.