Skip to content
Field Report · Vault Tier · Financial Services

Cooperative Bank

FranceActive since Mid-2023

One million customers. Two hundred branches. Four source systems. One definitional layer beneath the existing AML stack. No system replaced.

Executive Summary

A French regional cooperative bank serving more than one million customers across two hundred-plus branches and a multi-billion-euro loan book. Anti-money-laundering operations ran on a layered set of vendor systems — sanctions screening, rule-based transaction monitoring, and case management — that had grown by accretion. After the ACPR's April 2023 thematic review on automated AML surveillance, the bank's compliance leadership concluded the existing posture would not survive a near-term inspection. Stathon deployed at Vault Tier. Over twelve months, an event model consolidated transaction signals across the core banking system, the card backbone, the SWIFT/EBICS corporate channels, and the group's insurance entity into a single, customer-anchored stream. A probabilistic scoring layer was introduced beneath — not in place of — the existing rule-based monitoring. No system was replaced.

False-positive rate−35–50%Transaction-monitoring alerts
Capacity redirected~600–750 hrsPer month, to enriched investigation
Alert → déclaration≈ 2×Conversion rate doubled
New typologies14Surfaced in first production year
01 · The Environment

The institution.

A French regional cooperative bank operating a centralized core banking system in the COBOL-and-services-bus tradition characteristic of mutualiste banks at this scale. Card acceptance routes through GIE Cartes Bancaires with daily clearing. Corporate flows arrive via SWIFT and EBICS. The group's insurance entity runs on a separate policy-administration system with its own client-identifier scheme.

For AML/CFT, the bank operates a sanctions-screening platform widely deployed across French Tier-1 banks, a rule-based transaction-monitoring scenario engine running against the core banking general ledger, and a separate case-management front end where the AML analyst team works the queue.

What was absent was not a tool. What was absent was a layer at which a transaction observed at the card backbone, a customer profile maintained in the core, a beneficiary string on a SWIFT message, and a beneficial-owner declaration captured during onboarding could be understood as belonging to the same entity. None of the existing systems held the question — is this the same person, the same network, the same risk event?

System environment at engagement start
Core bankingCentralized COBOL + services-bus stack
Card backboneGIE Cartes Bancaires clearing
Corporate channelsSWIFT gateway · EBICS portal
Sanctions screeningPreserved · vendor name withheld
Transaction monitoringRule-based scenario engine · preserved
Case managementPreserved · vendor name withheld
Group insurance entitySeparate policy administration
Customers · branches1M+ customers · 200+ branches

Each system answered its own narrow question. The answers did not compose.

Core BankingLedgerNightly batch deltas, intra-day card data
GIE-CBCardClearing window, near-real-time authorization
SWIFT · EBICSCorporateNear-real-time message availability
InsuranceGroupDaily extract, separate identifier scheme
02 · The Challenge

Volume. Latency. Definition.

The visible problem was alert volume and alert latency. The transaction-monitoring engine produced a high-volume daily alert queue, far in excess of what the analyst team could triage in any structurally meaningful order. Alerts that should have been correlated — across joint accounts, across spouse-and-firm structures, across the insurance relationship — were treated independently. Cases reached the déclaration de soupçon threshold late or not at all.

The April 2023 ACPR thematic review documented this pattern industry-wide: alert-treatment delays reaching 95 days, monitoring perimeters with known exclusions, scenario thresholds calibrated to global rather than client-level averages. The June 2024 ACPR sanction against BRED Banque Populaire codified the supervisory expectation against which a regional bank of this size would now be measured.

The existing platform was not under-tuned. It was unable, by construction, to represent the questions a 2024-vintage AML inspection would ask. Tuning a scenario engine to detect what its data model cannot articulate produces the same alerts at lower thresholds — not different alerts.

Stathon engagement assessment
The entry point

The bank had received internal-audit findings flagging the same recurring failure modes the ACPR had begun citing in its decisions — accounts outside the monitoring perimeter, weak alert prioritization, slow examen renforcé cycles. Two prior remediation engagements with established consultancies had focused on scenario tuning and analyst process redesign; both reduced alert volume in the short term and produced negligible structural change. The bank's compliance leadership concluded that no further iteration of the existing pattern would address the supervisory exposure.

Identified definitional gaps
GAP-01
Customer

The customer in the core banking system, the cardholder in the card backbone, the policy holder in the insurance system, and the SWIFT beneficiary string were four representations of the same person. No system held that fact. Cross-system de-duplication relied on string matching on names and account numbers.

GAP-02
Beneficiary

Sanctions alerts on the same resolved beneficiary across systems were treated as independent events. A single counterparty could trigger redundant alerts at the SWIFT gateway, the card backbone, and the corporate channel — examined separately, escalated separately, closed separately. Entity resolution did not exist at the alert layer.

GAP-03
Event

Transaction signals from card, core, SWIFT, and insurance flows arrived in four schemas with four temporal cadences. The monitoring engine scored individual transactions against scenario thresholds. There was no consolidated, customer-anchored event stream against which patterns could be evaluated.

GAP-04
Risk relationship

Beneficial-owner declarations captured at onboarding were not connected to transaction monitoring. Spouse-and-firm structures, joint-account correlations, and shared-mandate networks were invisible to the alert pipeline. The bank’s systems could not represent a network-level risk question.

The structural diagnosis

The bank's systems did not share a definition of customer, beneficiary, event, or risk relationship across the AML perimeter. Beneficial-owner graphs were maintained in onboarding but not connected to transaction monitoring. The customer in the core, the cardholder in the card backbone, the policy holder in the insurance system, and the SWIFT beneficiary string were four representations of the same person — and no system held that fact.

03 · The Engagement

Three phases.

Vault-tier deployment from the beginning. Sovereignty over what is known, by whom, and when, was not a feature — it was the precondition for the bank's right to operate the system at all. French sovereign-cloud-qualified hosting. RBAC and audit governance reaching to the AI model layer. A chain of evidence sufficient for ACPR inspection.

Phase 1

Definition & Integration Spine

Weeks 1–14
ARCHÉDefinitional Authority
Entity graph: a single legal or natural person resolvable across core client number, cardholder reference, insurance policyholder ID, and SWIFT beneficiary fragment
Event schema: normalized record carrying source-system fingerprinting, idempotent state transitions, monetary amount, counterparty reference, channel, instrument
Compliance model: déclaration de soupçon under L.561-15 CMF, communication systématique under L.561-15-1, gel des avoirs under L.562-2
Beneficial-owner graphs from onboarding connected to the transaction perimeter for the first time
COREOperational Continuity
Nightly batch deltas from the core banking general ledger; intra-day card data via GIE-CB clearing
SWIFT messages via gateway with near-real-time availability; insurance entity via daily extract
Cross-system entity resolution in the Fellegi–Sunter tradition; m and u parameters trained on ~14,000 labeled identity pairs
Separate parameter regimes for retail and corporate clients; structured beneficiary-name normalization for SEPA business transfers
AEGISSovereignty & Protection
French sovereign-cloud qualified hosting (Article L.511-33 CMF banking-secret obligation)
RBAC policy with three subject classes: human analyst, internal model-validation function, AI model component
Audit event taxonomy: every model query against banking-secret-covered data logged with subject, version hash, timestamp, output
Five-year retention under L.561-12 CMF with cryptographic segregation between active and post-relationship states

The first work was not integration — it was definition. By week 14, no AI capability was live. The integration spine ran. The entity graph held the bank's resolved customer perimeter. The event log had backfilled 18 months of historical transactions. Aegis was operational — already producing audit-grade access logs the bank had not previously held.

Stathon deployment record
Phase 2

Athena — First Live Capabilities

Months 4–13
Probabilistic alert prioritization

The first capability deployed in production. Athena’s probabilistic scoring engine was layered beneath — not in place of — the legacy scenario engine. Every alert produced by the legacy engine continued to be produced. What changed was that each alert was scored, ranked, and presented to analysts in priority order, with the scoring engine drawing on the entity graph to consolidate alerts referring to the same entity or network across the bank’s systems.

90-day parallel-run validation

Internal model-validation approval required a 90-day parallel-run validation against the legacy queue order before the prioritization could alter the analyst’s working order. Both queues were maintained — analysts worked the legacy order, while the new prioritization ran in shadow and was reviewed weekly by the bank’s model-validation team. After approval, the prioritization layer cut over to live mode in October 2024.

Entity-resolved sanctions de-duplication

The second capability. The legacy sanctions filter continued to produce its alerts against EU Regulations 269/2014 and 833/2014, UN, OFAC, HMT, and the DGT registre national des gels. The engagement added an entity-resolution pass that collapsed multiple alerts on the same resolved beneficiary into a single examination unit — preserving each underlying alert in the audit trail but sparing the analyst the redundant work.

Night-shift cohort retraining

Initial detection consistency on night-shift cross-border flows ran approximately 12 percentage points below the day-shift baseline — a cohort imbalance traced to the historical training set under-representing weekend SEPA Instant volumes. Resolved in a separate tuning cycle over six weeks in November–December 2024.

PSAN flow carve-out

PSAN-related flows, included in the initial scoring track, were carved out into a separate pipeline in early 2025 after their velocity profile produced an unacceptable false-positive rate against the same threshold. The carved-out track now runs in advisory mode pending the post–1 July 2026 MiCA transition.

November 2024

A cluster of three corporate accounts — opened within four months in three different branches across two regions — received cumulative inbound transfers of ~€1.2M from a single Limassol-incorporated entity. Individually, each account remained below the legacy engine's escalation threshold. The probabilistic scoring layer correlated the three through a shared signing-mandate beneficial owner. Consolidated alert raised within 11 minutes of the third deposit clearing. Déclaration de soupçon filed with Tracfin within 96 hours.

February 2025

A cluster of seven recently opened personal accounts — holders aged 19 to 24, each receiving inbound card-fraud-victim funds — was flagged by a fan-in network pattern in the entity graph. The flag preceded the typical end-of-week ATM withdrawal cycle by approximately nine hours. Branch-level intervention was possible on five of the seven accounts before extraction. Pattern added to the bank's internal mule-typology library.

Phase 3

Expansion & Roadmap

Current · ongoing

Three workstreams active. The entity perimeter is being extended to the group's life-product flows — historically outside the AML monitoring perimeter and a recurring grief category in recent ACPR decisions against insurer entities. The adverse-media context feed is in pilot under examen renforcé only. A CASP/PSAN flow scoring track is in design ahead of the 1 July 2026 PSAN-to-MiCA transition.

Insurance perimeter extension

Entity graph and event schema integration completed for the group’s life-product flows. Scoring track in advisory mode pending the bank’s internal-validation review. Closes a perimeter gap repeatedly cited in ACPR decisions against insurer entities.

Adverse-media context feed

In pilot. Surfaces supplementary information to analysts during examen renforcé. Not currently used as a scoring input — a deliberate constraint pending an internal model-validation cycle on its precision profile.

PSAN/CASP scoring track

In design ahead of the 1 July 2026 PSAN-to-MiCA transition deadline. Given the 339% YoY increase in PSAN-origin déclarations de soupçon in 2022–2023 and a further 112% in 2024, prioritized for full production by Q4 2026.

04 · Outcomes

What changed.

Outcomes stated against the 12-month measurement window covering the closure of the parallel-run validation in October 2024 through October 2025. Each figure sourced from the bank's internal model-validation reports and the AML operations team's quarterly metrics review.

False-positive rate
Baseline
−35–50%
Transaction-monitoring alerts, 12-mo window
Capacity redirected
Triage queue
~600–750 hrs/mo
From triage to enriched investigation
Alert → déclaration
Baseline
≈ 2×
Conversion rate on prioritized queue
Typologies surfaced
0
14
Added to internal scenario taxonomy
Sanctions de-dup
Did not exist
Live
Entity-resolved at examination unit
Decision cycle
Days–weeks
Seconds
Prioritized alert ordering, structural shift
Nature of the change

The decision cycle on prioritized alerts compressed from the days-and-weeks pattern characteristic of the pre-deployment queue to a near-real-time pattern measured in seconds — a structural shift, not a speed improvement. The bank's compliance function now sees alerts in the order in which they should be worked, not in the order in which the legacy scenario engine produced them.

Capacity redirection

The ~600–750 hours per month previously spent on triage were not eliminated. They were liberated from the lower-value end of the workflow and redeployed into examen renforcé, typology development, and the work the bank's compliance function had previously been unable to staff.

05 · Observations

What this case revealed.

Tuning was not the answer

Two prior remediation engagements with established consultancies had focused on scenario tuning and analyst process redesign. Both reduced alert volume in the short term and produced negligible structural change. What two prior partners had described as a tuning problem — to be addressed with better thresholds and more analysts — was a definitional problem: a question of whether the bank’s own systems shared a common understanding of what counted as a customer, an event, or a network. Until that question was answered, no amount of tuning could produce the alerts an inspection would expect.

The probabilistic layer beneath, not in place of

The legacy rule-based scenario engine remained the source of truth for whether an alert existed. The probabilistic layer ranked which alerts deserved attention first. This was not a transitional arrangement. It is the architecture: the rule-based engine carries the regulatory burden of explicit detection logic; the probabilistic layer carries the operational burden of priority. Each does what it does well; neither is asked to do what it cannot.

Human-in-the-loop as architectural decision

From the engagement’s outset, examen renforcé and déclaration de soupçon drafting remained human. This posture was subsequently confirmed by the April 2025 update to the ACPR–Tracfin lignes directrices conjointes, which explicitly endorsed AI-supported alert detection while mandating human control for those activities. The constraint was architectural — not regulatory accommodation, not a transitional state.

Sovereignty as precondition

The Vault-tier configuration is not a stricter version of the same product. It is the same architecture configured for an environment in which sovereignty over what is known, by whom, and when, is not a feature — it is the precondition for the bank’s right to operate the system at all. Sovereign-cloud-qualified hosting, RBAC and audit governance reaching to the AI model layer, retention and lineage compliant with Article L.561-12 CMF, and a chain of evidence sufficient for ACPR inspection are not bolted-on properties. They are structural.

The bank received structural capacity, not software. The integration is not visible from the surface. Its absence would be.

Stathon deployment conclusion
06 · Forward

Forward roadmap.

In production
Probabilistic alert prioritization across consolidated event stream (live since October 2024)
Entity-resolved sanctions-alert de-duplication
In pilot · advisory
Adverse-media context surfacing during examen renforcé
Insurance-entity perimeter extension
PSAN/CASP-flow scoring track
On roadmap
Trade-based money-laundering pattern detection
UBO-graph reconciliation against the national PSC register
Federated typology exchange under ACPR sandbox (early review)
Q4 2025

Adverse-media context pilot

Surfaced to analysts during examen renforcé as supplementary context. Not currently used as a scoring input — a deliberate constraint pending an internal model-validation cycle on its precision profile. The constraint is architectural, not transitional.

Q2 2026

Insurance-entity perimeter extension

The entity perimeter is being extended to the group’s life-product flows — historically outside the AML monitoring perimeter and a recurring grief category in recent ACPR decisions against insurer entities. Entity graph and event schema integration completed; scoring track in advisory mode pending the bank’s internal-validation review.

1 July 2026

PSAN/CASP scoring track for MiCA

Carved out from the main scoring pipeline in early 2025; runs in advisory mode pending the PSAN-to-MiCA transition. Given the 339% YoY increase in PSAN-origin déclarations de soupçon in 2022–2023 and a further 112% in 2024, this track is prioritized for full production by Q4 2026.

07 · Engagement Parameters

Deployment record.

Engagement typeVault Tier · Financial Services
Engagement startMid-2023
Phase 1 completeWeeks 1–14 · integration spine
Phase 2 cutoverOctober 2024 · post 90-day parallel run
Current phasePhase 3 — typology expansion + perimeter extension
Scale1M+ customers · 200+ branches · multi-billion-euro loan book
HostingFrench sovereign-cloud qualified
Regulatory frameworkACPR · Tracfin · CMF · DORA · GDPR · EU AI Act
Systems modifiedNone — definitional layer beneath the existing stack

Stathon · Definitional Infrastructure Company. Client identity withheld by agreement. Deployment metrics reflect production conditions as of May 2026.