01
Event-Driven
Every transaction, authentication, profile change and case action is an immutable event on the backbone. Components subscribe; they do not poll.
Bucephalus is an event-driven, AI-augmented platform for detecting and preventing fraud and money laundering in banking. It is built for real-time decisioning, verifiable audit, regulatory alignment, and deployment inside the bank's own trust boundary — on-premise or in a private or sovereign regional cloud.
The six decisions the architecture is organised around. Every component below inherits these constraints.
Every transaction, authentication, profile change and case action is an immutable event on the backbone. Components subscribe; they do not poll.
Authorisation-path scoring completes within the issuer response budget. Batch is reserved for model training and retrospective analysis.
Each capability is an independently deployable service with a versioned contract. Banks deploy only the modules they need.
Processing uses the smallest identifier set required for the decision. Raw PII stays inside the institution's trust boundary.
Every decision is reproducible from the original event plus the exact feature values and model version used to score it.
Runs on-premise, in a bank's private cloud, or in a sovereign regional cloud. No dependency on a vendor-controlled tenant.
The platform splits cleanly along its latency budget. The real-time plane operates inside the authorisation response window; the compliance plane runs over longer horizons with richer context.
The integration layer normalises inbound events onto a single streaming backbone. The real-time plane consumes events inside the authorisation response window; the compliance plane consumes the same events over longer horizons with additional enrichment. Every decision and action is reflected into the audit and data platform on the right.
Eight services, each independently deployable, each sharing one audit-grade event log.
Canonicalises heterogeneous banking events into a single domain model.
Adapters for ISO 20022, ISO 8583, SWIFT MT / MX, PSD2 XS2A, and proprietary core-banking protocols. Inbound events are validated, normalised, enriched with reference data, and emitted onto the backbone with stable correlation identifiers.
Durable, partitioned event log with replay and backpressure.
Log-structured, at-least-once delivery with per-key ordering (account and customer). Windowed joins, schema evolution via a registry, exactly-once semantics for sink writes. Sized for sustained millions of events per second at Tier-1 volumes.
Hybrid rule + ML scoring on the authorisation path.
A declarative rule DSL runs alongside gradient-boosted and deep-learning models. A feature store supplies consistent online / offline features. Shadow evaluation lets new rules and models run silently in production before promotion. Target p99 inline latency is tens of milliseconds.
Scenario-based, behavioural and graph-based detection.
Statistical baselining per customer segment, FATF-aligned typologies (structuring, layering, smurfing, trade-based ML), and graph analytics over the counter-party network to surface mule rings and layering chains. Outputs are cases, not raw alerts.
Real-time and batch list screening with linguistic matching.
Exact, fuzzy (Levenshtein, Jaro-Winkler), phonetic (Double Metaphone), and transliteration matching against EU consolidated, OFAC, UN, and national lists. Lists refresh continuously; every hit is explainable back to the rule and list version.
Workflow, evidence and SLA control for investigators.
Configurable queues, four-eyes approvals, evidence attachment with chain-of-custody, SLA timers with escalation, integrated STR / SAR drafting, and bidirectional links to the originating events and decisions.
Tamper-evident record of every decision and change.
Append-only, hash-chained log covering events, feature values, model versions, rule versions, analyst actions and configuration changes. WORM-compatible retention; reproducing any past decision requires only the audit store.
Operational, analytical and graph stores behind a unified access layer.
Low-latency operational store for live features, a columnar analytical store for investigation and reporting, and a graph store for network analysis. Tiered retention balances regulatory minima with cost; lineage is captured end-to-end.
The full picture: every inbound source, every processing lane, every feedback loop. The diagrams in this section are intentionally high-level — rule logic, model internals, tuning procedures, internal data models and specific optimisation techniques are not part of this public description.
flowchart LR
A[Banking & external
source systems] --> B[Integration &
normalisation layer]
B --> C[Event & data
backbone]
C --> D[Real-time
decisioning]
C --> E[Continuous AML
monitoring]
C --> F[Sanctions &
watchlist screening]
D --> G[Decision &
channel response]
D --> H[Alert generation]
E --> H
F --> H
H --> I[Case management &
investigation workbench]
I --> J[Reporting &
regulatory export]
D --> K[Audit &
logging layer]
E --> K
F --> K
I --> K
K --> J
C --> L[Data platform
& analytics]
L --> M[Model & pattern
refinement]
M --> D
M --> E
N[Federated intelligence layer] --> M
M --> N
Four representative sequences, one per operational mode. Each is a view of the same underlying event-driven platform seen from a different time horizon and a different stakeholder.
Inside the authorisation response window — the channel is waiting on a synchronous answer.
sequenceDiagram
autonumber
participant CH as Channel / core system
participant IG as Integration layer
participant EB as Event & data backbone
participant DE as Decision engine
participant SS as Sanctions screening
participant AM as AML / fraud scoring
participant AL as Audit log
participant CM as Case management
CH->>IG: Transaction / event
IG->>IG: Validation & normalisation
IG->>EB: Structured event
EB->>DE: Decision request
DE->>SS: Fast screen
SS-->>DE: Screening result
DE->>AM: Risk & behavioural scoring
AM-->>DE: Risk result
DE->>DE: Aggregated decision logic
DE->>AL: Decision + rationale metadata
alt Approve
DE-->>CH: Approved
else Further review needed
DE->>CM: Alert / case
DE-->>CH: Step-up / review
else Block
DE->>CM: Critical alert / case
DE-->>CH: Decline / block
end
Over the compliance horizon — hours to months — with the analyst workbench in the loop.
sequenceDiagram
autonumber
participant SRC as Source systems
participant IG as Integration layer
participant EB as Event & data backbone
participant AML as AML monitoring
participant SL as Sanctions / list check
participant AG as Alert handling
participant CASE as Case management
participant AN as Analyst
participant REP as Reporting
participant AUD as Audit log
SRC->>IG: Transaction & related events
IG->>EB: Normalised events
EB->>AML: Monitoring
EB->>SL: List & match check
AML-->>AG: AML risk signal
SL-->>AG: Screening hit / match
AG->>CASE: Create & prioritise case
CASE->>AUD: Case-open log entry
AN->>CASE: Open case
CASE-->>AN: Events, history, related items
AN->>CASE: Decision / note / next action
CASE->>AUD: Analyst actions
alt Reportable
CASE->>REP: Generate regulatory report
REP->>AUD: Export log entry
else Internal closure
CASE->>AUD: Closure log entry
end
How defensive capability travels between institutions while raw data stays at home.
sequenceDiagram
autonumber
participant B1 as Institution node A
participant GOV as Sharing governance
participant FP as Federated coordination
participant B2 as Institution node B
participant AUD as Audit log
B1->>GOV: Prepare shareable pattern / aggregated signal
GOV->>GOV: Check & filter
GOV->>AUD: Sharing decision
GOV->>FP: Approved, non-raw-data-shaped pattern
FP->>B2: Pattern / regulatory intelligence
B2->>AUD: Ingest & apply
What an internal auditor or an external supervisor actually sees when they pull a trail.
sequenceDiagram
autonumber
participant DET as Detection & decisioning layers
participant CASE as Case management
participant AUD as Audit & logging
participant REP as Reporting module
participant SUP as Internal / external reviewer
DET->>AUD: Events & decision metadata
CASE->>AUD: Analyst & workflow actions
REP->>AUD: Report generation request
AUD-->>REP: Traceable event chain
REP-->>SUP: Auditable report / export
The diagrams above are deliberately kept at platform level. Internal rule logic, modelling methodology, tuning procedures, internal data models and specific optimisation techniques are not part of this public description.
Bucephalus processes some of the bank's most sensitive data. The security model is zero-trust by default and assumes compromise at any single layer.
Every service-to-service call is mutually authenticated with mTLS and short-lived SVID-style identities. No implicit network trust.
Root keys in FIPS 140-2 L3 HSMs, envelope encryption for data at rest, rotation and attestation as first-class operations.
Operators cannot read decision content; analysts cannot alter audit records; model promoters cannot approve their own releases.
Container images, models and rule bundles are signed and verified at deploy time. SBOMs are emitted and retained per release.
PII processing, pseudonymisation and k-anonymisation happen before any cross-boundary transfer — including to the federation layer.
No long-lived credentials in services. Workload identity is issued dynamically and bound to the request context.
Banks in the network improve each other's detection without raw data ever leaving any participant's trust boundary. The federation layer enforces a narrow, auditable contract for what is and is not allowed to cross institutional lines.
Observability is structured the same way a bank operations centre expects it.
The decisioning plane is on the critical path for customer payments. Its availability targets reflect that.
The platform is aligned with the regulations that actually apply to the use case. The list below is indicative, not exhaustive, and evolves with the regulatory perimeter.
Real-time where the attacker is fast, forensic where the regulator is patient, federated where cooperation helps, sovereign where data must stay. Bucephalus combines these properties into a single operational platform that a bank can run inside its own trust boundary.