Real-time decisioning architecture for the bank
Fraud, AML, credit, NBA, retention triggers — all need sub-second decisioning. Architecture of the layer in the bank.
Discuss Your ChallengeWhat is real-time decisioning in a bank
Every customer interaction has a potential decision: approve transaction or block, show offer, escalate, log audit. Without a centralised layer — decisions scattered, inconsistent.
Banking decisioning consolidates: trigger event → context fetch → policy + model evaluation → decision + audit.
Structural components
Trigger ingress. Events from event bus, channels, transactions.
Context fetch. Profile from CDP, current state (balance, recent activity, active cases).
Policy engine. Declarative rules (regulatory, risk appetite, customer preferences). Change without deploy.
Model serving. ML models (PD, fraud score, propensity). Versioned, A/B-able.
Decision logic. Combination of policies + model scores + business rules.
Audit trail. Every decision with full input, models, policies, output, owner.
A/B framework. Decision compared to alternative for learning.
Latency budget
Banking specific:
- Card authorisation: <500ms end-to-end (network limit).
- Online banking transaction: <1s acceptable.
- Retail credit decision: <5s.
- Mobile app NBA: <500ms.
Budget allocation:
- Trigger ingress 20-50ms.
- Context fetch 30-80ms.
- Model serving 20-100ms.
- Policy evaluation 10-30ms.
- Decision logic 10-30ms.
- Audit (async) 10-30ms.
Where banking-specific is harder
Regulatory traceability. Every automated decision must be explainable per regulator (especially for credit and AML).
Model bias. Credit models in particular — disparate impact monitoring mandatory.
Override audit. Manual overrides — full chain of approval.
False positive cost. Blocking a legitimate transaction — customer churn.
Where it usually breaks
Latency not measured — channels timeout.
Policies in code — changes require deploy.
Models not retrained — accuracy decays unnoticed.
Audit incomplete — investigation cases impossible.
A/B testing impossible — product does not learn.
Operating model
Owner — Head of Decisioning, between risk and technology.
Teams: platform engineering, decision science, policy management, channel integration.
Routine — weekly decision review, monthly model review.
Related
- /en/architecture/banking-cdp-architecture/ — context source
- /en/architecture/banking-event-bus-architecture/ — event bus
- /en/architecture/banking-mlops-architecture/ — MLOps
- /en/solutions/banking-credit-decisioning-platform/ — credit decisioning
What else is worth exploring
Topics from the same area we usually explore together
CRM
Not an off-the-shelf CRM, but a properly built customer management contour — from first contact to loyalty.
→SolutionBI
Analytics is not pretty charts on the wall. It's the answer to 'why?' before the problem becomes a loss.
→SolutionContact Center
The contact center is not a phone station — it's the point where a client decides: stay with you or leave. The question is how it's built…
→SolutionOnboarding
Onboarding is your company's first impression. If it takes 5 days and 12 paper forms, there won't be a second impression.
→I do not just write about this. I can come in, examine your situation and design a solution for your specific landscape.
Discuss applying this →Ready to discuss your challenge?
Tell me what's not working or what needs to be built. First conversation — no obligations.
Usually respond within a few hours