Skip to content
Deploint

Case study 04 / Financial Services

Real-Time Financial Intelligence

A streaming architecture that scores transactions for risk in flight and gives analysts an auditable trail from signal to decision.

Concept Architecture

Illustrative reference architecture, not a client engagement. Outcomes described here are design goals, not measured results.

Talk to an EngineerExplore the architecture

Reference flow

05 stages

Reference flow for Real-Time Financial Intelligence: Transactions, then Stream, then Features, then Risk models, then Analyst console.

01Challenge

Why this problem is hard.

Risk decisions on payments and transfers have to be made while the transaction is in flight, inside the latency budget of the payment flow. Batch scoring finds problems after funds have moved, and rules alone struggle to keep pace with changing patterns. Every decision must also be explainable to analysts and auditors.

  • 01

    A hard latency budget

    Scoring sits in the authorization path. It must answer within a fixed budget or fall back to a safe default.

  • 02

    Feature freshness

    Useful signals, such as recent activity per account or device, change by the second and must be computed on the stream.

  • 03

    Training and serving skew

    Features computed one way for training and another way in production quietly degrade model behavior.

  • 04

    Audit and explanation

    Analysts need to see why a transaction was held, and auditors need to reconstruct the decision later.

02Business context

Assumptions and constraints.

The concept assumes a payments or banking platform with an existing core system, a rules engine and an analyst team that reviews held transactions. Model risk management practice requires every production model to be documented, validated and monitored.

Constraints the design must respect

01Deterministic fallback
If scoring is unavailable, the payment flow continues under defined rules. The model is never a single point of failure.
02Data minimization
Only attributes needed for risk scoring enter the stream. Sensitive fields are tokenized at the producer.
03Reproducibility
Each decision stores model version, feature values and rule outcomes so it can be replayed.
04Separation of duties
Model developers, validators and operators hold distinct roles and access.

03Architecture

Reference architecture.

Seven stages from transaction event to audited decision. Everything in the authorization path has a timeout and a fallback. Select a stage to see what it does and the components involved.

Authorization requests and account events are published to an event stream by the core platform, with sensitive fields tokenized at the producer.

  • Event schemas
  • Schema registry
  • Field-level tokenization
  • Idempotent producers

Key patterns

  • Stateful stream processing
  • Online / offline feature store
  • Shadow scoring
  • Replayable decisions

04Technology

Representative technology.

Technologies we would consider for this concept. Final selection follows the organization's existing standards, skills and estate. Listing a technology does not imply a vendor relationship.

  • 01

    03 items

    Streaming

    • Kafka-compatible event streaming
    • Schema registry
    • Stateful stream processor (e.g. Apache Flink)

  • 02

    04 items

    ML platform

    • Feature store (online and offline)
    • Model registry
    • Low-latency model serving
    • Gradient-boosted tree models

  • 03

    04 items

    Application

    • Rules engine
    • Case management service
    • Entity graph queries
    • Low-latency APIs

  • 04

    04 items

    Security & governance

    • Tokenization service
    • Fine-grained access control
    • Immutable audit storage
    • Key management

05Engineering approach

Principles behind the design.

The decisions that shape every stage of the architecture, and why we would hold to them under delivery pressure.
  1. 01

    Design to the latency budget

    Every component in the authorization path has a timeout and a fallback, and the path is load-tested before release.

  2. 02

    One feature definition

    Features are defined once and materialized to both stores, removing a major source of training and serving skew.

  3. 03

    Rules and models together

    Rules encode known policy; models capture patterns rules miss. Both are versioned and visible to analysts.

  4. 04

    Every decision replayable

    Storing inputs, versions and outputs makes past decisions explainable, auditable and re-testable.

06Implementation

A phased delivery path.

Each phase ends with a working, reviewable increment and an explicit decision on whether and how to continue.

Delivery path

04 phases

Delivery phases: Data & decision mapping, then Streaming foundation, then Shadow scoring, then Controlled activation
  1. 01Data & decision mapping
  2. 02Streaming foundation
  3. 03Shadow scoring
  4. 04Controlled activation
  1. Phase 0101

    Data & decision mapping

    Map events, existing rules, decision points, latency budgets and audit requirements with risk, compliance and engineering.

    Deliverables

    • Event inventory
    • Decision flow map
    • Latency budget
    • Model governance plan
  2. Phase 0202

    Streaming foundation

    Event publishing, schema governance and the first stream features, running in shadow mode.

    Deliverables

    • Event stream and schemas
    • Stream feature jobs
    • Feature store
    • Data quality checks
  3. Phase 0303

    Shadow scoring

    Models score live traffic without affecting decisions; results are compared with rules and analyst outcomes.

    Deliverables

    • Scoring service
    • Shadow comparison reports
    • Reason codes
    • Validation package
  4. Phase 0404

    Controlled activation

    Enable model-informed decisions for a limited segment, then widen as monitoring confirms expected behavior.

    Deliverables

    • Policy configuration
    • Analyst console
    • Monitoring and alerts
    • Runbooks

07Intended outcomes

Design goals, not results.

What this architecture is designed to achieve. These are intended outcomes for a concept, not measured results from a client engagement.

  • Design goal 01Intended

    Decisions while funds are in flight

    Risk is assessed in the authorization path rather than after settlement.

  • Design goal 02Intended

    Explainable holds

    Analysts see reason codes and related activity, not just a score.

  • Design goal 03Intended

    Consistent features

    Training and production share feature definitions, reducing silent degradation.

  • Design goal 04Intended

    Audit-ready by design

    Any past decision can be reconstructed with the data, model and policy versions that produced it.

Concept Architecture

No figures are attached to these goals. Actual results depend on the environment, data and delivery, and would be measured against baselines agreed at the start of a real engagement.

08Lessons & risks

Engineering lessons and risks to manage.

Where designs like this tend to run into trouble, and what we would plan for from the start.

  • Risk 01

    Shadow mode is not optional

    Scoring live traffic without acting on it is how teams learn a model's real behavior before customers feel it.

  • Risk 02

    Labels arrive late

    Confirmed fraud and disputes can take weeks to surface. Training pipelines must handle delayed and noisy labels.

  • Risk 03

    Adversaries adapt

    Patterns shift in response to controls. Drift monitoring and retraining cadence belong in the design.

  • Risk 04

    Fallbacks need exercising

    A fallback that has never run is a hypothesis. Failure testing should cover scoring outages.

Start an engineering conversation

Facing a similar engineering problem?

Bring us the problem and the constraints around it. We'll help architect the system.

Talk to an EngineerView Case Studies