Explainable risk, scoring & fraud intelligence
Score in real time. Explain every decision.
Prism scores payments, credit applications and account activity as they happen, combining business rules and machine-learning models in a single decision. Every outcome arrives with ranked reason codes and factor contributions, so analysts and auditors see why a decision was made, not only what it was. It is built to run on-premises first, inside your own security perimeter.
VARDA PrismRuns on Orbit
The problem
A score you cannot explain is a score you cannot defend.
Fraud patterns shift faster than rule sets can be rewritten, and models are often retrained without a clear record of what changed. When a customer disputes a decision or an inspector asks for evidence, the answer is scattered across logs, spreadsheets and the memory of whoever was on shift.
- 01
Rule sets that have grown for years and now contradict each other
- 02
Models whose decisions cannot be explained to a customer or an inspector
- 03
False positives that fill analyst queues and turn good customers away
- 04
No single record of who decided what, when, and with which model version
- 09:41:18TRX-8F21AFAST₺ 4.250,00212APPROVE
- 09:41:17TRX-8F219Card₺ 38.900,00812REVIEW
- 09:41:15TRX-8F214EFT₺ 12.480,00164APPROVE
- 09:41:14TRX-8F211Card₺ 1.199,9096APPROVE
- 09:41:12TRX-8F20CFAST₺ 96.000,00944BLOCK
- 09:41:11TRX-8F208EFT₺ 7.310,00301APPROVE
- 09:41:09TRX-8F203Card₺ 649,0058APPROVE
- New device, first seen+142
- Unusual hour for this customer+96
- Amount 6.2× the 90-day average+88
- First-time beneficiary+71
- Long customer tenure-38
risk-gbm v4.2 · rule set 2026.09 · decision log #9f3a…c21e
Capabilities
Every decision, split into its spectrum.
Real-time scoring
Rules and a model ensemble evaluate each transaction in a single call, within the latency budget of your authorisation flow. The outcome is approve, decline, step-up authentication or review.
Reason codes for every decision
Each score returns with ranked reason codes and SHAP-based factor contributions, worded so that an analyst can act on them and a customer can be told.
Case management and reporting
Alerts become cases with their full context: transaction history, linked accounts, reason codes and earlier decisions. Assignment rules, four-eyes approval, SLA timers and MASAK report drafts are part of the workflow.
Immutable decision log
Every decision is written to an append-only, hash-chained log with the model version, feature values, thresholds, rules fired and the person or service that acted. Any decision can be replayed exactly as it was made.
Champion–challenger and monitoring
New models and rule changes run in shadow mode on live traffic before they decide anything. Drift, stability and alert rates are tracked per segment, and promotion is an approved, recorded step, never a silent deployment.
Shared feature store
Velocity counters, behavioural profiles and relationship features are defined once and served identically to training and to live scoring. Point-in-time correct training sets prevent training–serving skew.
How it works
From event to explained decision
Capture
Transactions arrive through a synchronous API call from the authorisation flow, or as events from core banking through CDC and Kafka.
Enrich
The feature store adds velocity counters, device and behavioural profiles, and relationship features within the same request.
Score
Deterministic rules and the model ensemble run side by side, and a decision policy turns their outputs into approve, decline, step-up or review.
Explain and record
Reason codes and factor contributions are attached to the decision, and its full context is committed to the immutable log.
Review and learn
Cases that need a person go to analysts. Their outcomes and confirmed fraud labels flow back to evaluate challengers and retrain models.
Architecture
VARDA Prism · Architecture
01 Sources
- Core banking (CDC)
- Card & payment channels
- Device & session signals
02 Processing
- Event stream
- Feature store
03 VARDA Prism
- Prism decision engine
- Reason codes & contributions
04 Outputs
- Real-time decision
- Case management
- Immutable decision log
- Regulatory exports
Use cases
Use cases
Prism sits in the authorisation path for card payments, EFT and FAST transfers, and scores each one before money moves. Suspicious payments are held for step-up authentication or analyst review rather than declined outright.
- Velocity, device and beneficiary-risk features computed in-stream
- Account-takeover and mule-account patterns flagged with their reasons
- Thresholds tuned per channel and segment, with every change recorded
Application scorecards and machine-learning models run under one decision policy, and every approval or decline returns with the factors behind it. Decline reasons can be given to applicants in plain language, and contested decisions go to a person for review.
- Scorecards and gradient-boosted models side by side
- Reason codes mapped to customer-facing explanations
- Challengers evaluated on live applications before promotion
Scenario rules and behavioural models follow accounts over days and weeks, not only single payments. Analysts investigate linked activity in one case and prepare suspicious-transaction report drafts for submission to MASAK.
- Structuring, rapid pass-through and dormant-account reactivation scenarios
- Network views linking accounts, devices and counterparties
- Case outcomes and report drafts kept with their full evidence trail
Deployment options
Deployment options
On-premises
The default for banks. Prism runs on your own Kubernetes clusters or virtual machines in your data centre, with no outbound dependency at decision time; models, logs and keys stay under your control.
Private cloud
For institutions with their own private cloud or a regulated, in-country provider. The same container images and Helm charts are deployed into your tenancy, and data stays in Türkiye.
Hybrid
Scoring and the decision log stay on-premises, while model training and challenger evaluation run in a private-cloud environment on pseudonymised data.
Technical specification
VARDA Prism
- Decision latency
- p99 < 50 ms (design target)
- Scaling and availability
- Horizontal scaling; active–active across two data centres
- Decision outcomes
- Approve · Decline · Step-up · Review
- Explainability
- Ranked reason codes and SHAP contributions per decision
- Model support
- Scorecards, gradient boosting, anomaly models; ONNX and PMML
- Decision log
- Append-only, hash-chained; retention set by your policy
- Interfaces
- REST and gRPC decision API; Kafka streaming
- Access and change control
- Role-based access, SSO via SAML/OIDC, four-eyes approval
Integrations
- ISO 8583
- ISO 20022
- Apache Kafka
- Debezium
- Oracle Database
- IBM Db2
- PostgreSQL
- REST / gRPC
- ONNX
- MLflow
- LDAP / Active Directory
- SAML 2.0 / OIDC
- Syslog / SIEM
Compliance & governance
- Designed to support the audit-trail, access-control and in-country data requirements of the BDDK regulation on banks’ information systems and electronic banking.
- Designed to support MASAK obligations under Law No. 5549, including suspicious-transaction report preparation, record retention and evidence trails.
- Designed to support KVKK and GDPR requirements, including data minimisation, pseudonymisation and the right to contest decisions based solely on automated processing.
- Designed to support ISO/IEC 27001-style controls: role-based access, four-eyes change approval, encryption in transit and at rest, and tamper-evident logs.
Frequently asked questions
Frequently asked questions
01Does Prism replace our existing rules engine?
It does not have to. Prism can run your existing rules alongside its models, or sit behind your current engine and add a model score and reason codes to each call. We recommend starting in shadow mode and moving rules across gradually, once outcomes have been compared on live traffic.
02How are explanations produced, and can we share them with customers?
For tree-based models, contributions are computed with TreeSHAP; for scorecards, they are the points each attribute adds, and rules report the conditions that fired. Contributions map to a reason-code catalogue owned by your risk and legal teams, and each code can carry customer-facing wording. What is disclosed, and to whom, remains your policy decision.
03Can our data scientists bring their own models?
Yes. Models trained in Python can be imported as ONNX or PMML, or served as containers behind a standard interface, and are registered with their training-data reference, metrics and approver. They enter as challengers and decide nothing until they are promoted.
04What happens if Prism is unavailable during an authorisation?
The calling system never waits indefinitely. Each integration has a timeout and a fallback policy you define, such as approving below a set amount or switching to rules-only scoring. Prism is designed to run active–active across two sites, and every fallback decision is logged and flagged for review.
05How do we evidence a decision to an auditor or to MASAK?
Each decision record holds the input, feature values, model and rule versions, thresholds, outcome, reason codes and any analyst action, chained by hashes so that any alteration is detectable. An auditor can retrieve the record and replay the decision exactly. Suspicious-transaction report drafts and periodic exports are produced from the same records.
See VARDA Prism with your own data.
Real-time transaction scoring that combines rules and machine learning, with reason codes, case management and an immutable log for every decision.