Banking, Payments & Credit
Transaction Fraud Scoring API
Fraud decisions happen in the few hundred milliseconds between a customer pressing pay and your system answering. Everything useful has to arrive inside that window.
- Payment processors
- Banks
- Marketplaces
- Fintech platforms
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Fraud scoring sits in the most unforgiving part of a payment stack. It must answer in well under a second, it must be right often enough that losses stay inside appetite, and it must be wrong rarely enough that genuine customers are not turned away. Those three constraints pull against each other constantly.
Most teams start with rules, because rules are explainable and fast to write. Rules then accumulate: a few dozen becomes a few hundred, nobody remembers why half of them exist, and the false-positive rate climbs quietly until a merchant complains about declined good customers.
The durable answer is a scoring service that combines a model with rules deliberately — the model for patterns nobody has written down, the rules for the policies you must be able to state and defend — and that explains every score it returns. Explainability is not optional here: analysts need it to work cases, and in many jurisdictions customers are entitled to a reason.
Who buys this
Payment processors, Banks, Marketplaces, Fintech platforms
What the API returns
What comes back
- Transaction risk score with the factors that drove it, per request
- Account takeover indicators from device, session and behavioural signals
- Velocity and pattern analysis across configurable windows
- Device and network reputation signals
- Behavioural biometrics where your client supports collection
- Network analysis linking related accounts, devices and payment instruments
- Policy rules evaluated alongside the model, with rule hits reported separately
- Score reason codes suitable for both analyst review and customer communication
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/score | Score a transaction or account event synchronously |
| POST | /v1/score/batch | Score historical events in bulk for tuning |
| GET | /v1/entities/{id}/profile | Risk profile and history for an entity |
| POST | /v1/feedback | Report confirmed fraud and confirmed-good outcomes |
| GET | /v1/rules | Current policy rules and their recent hit rates |
| POST | /v1/simulate | Replay historical traffic against a proposed configuration |
Request and response
illustrativeRequest
{
"event_type": "card_payment",
"amount": { "value": 849.00, "currency": "EUR" },
"customer": { "id": "cust_41827", "account_age_days": 412 },
"instrument": { "token": "tok_9f21", "bin_country": "DE" },
"device": { "fingerprint": "df_77c1", "ip": "203.0.113.42" },
"context": { "merchant_id": "m_5521", "channel": "web" }
}Response
{
"score": 78,
"decision": "review",
"latency_ms": 41,
"reasons": [
{ "code": "DEVICE_NEW_TO_CUSTOMER", "weight": 0.31,
"detail": "Device first seen 4 minutes ago" },
{ "code": "AMOUNT_VS_HISTORY", "weight": 0.24,
"detail": "7.8x the customer's median transaction" },
{ "code": "IP_COUNTRY_MISMATCH", "weight": 0.18,
"detail": "IP country differs from billing and 90-day history" }
],
"rules_triggered": [
{ "rule_id": "R-118", "name": "High value on new device", "action": "review" }
],
"network": { "linked_accounts": 2, "shared_device_accounts": 3 },
"customer_message": "We need to confirm this payment before it completes."
}Where the data comes from
| Your transaction history | Past transactions with confirmed outcomes — the single most valuable input, and one you already have |
| Device and session signals | Collected by your client SDK: fingerprint, timing, navigation and input characteristics |
| Network and IP intelligence | Proxy, hosting and anonymiser indicators from a licensed reputation source |
| Payment instrument metadata | BIN data, issuer country and instrument type |
| Chargeback and dispute records | Confirmed fraud outcomes, which are what the model is actually trained to predict |
| Consortium signals where permitted | Cross-institution indicators, only where participation terms and data protection law allow |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Gradient-boosted models on engineered behavioural features, which consistently outperform deep models on tabular payment data
- Velocity features across many time windows and entity types simultaneously
- Graph features linking accounts, devices and instruments to surface organised activity
- Per-reason attribution on every score so analysts and customers both get an explanation
- Explicit policy rules evaluated alongside the model, never buried inside it
- Threshold optimisation against your actual cost of fraud versus cost of friction, not a generic default
- Drift monitoring, because fraud patterns change faster than almost any other modelled behaviour
- Champion/challenger deployment so a new model is proven on live traffic before it takes over
What it changes for the business
Loss reduction
Measurable against your current baseline, and measured honestly during a shadow period before cutover.
Fewer false declines
Better separation means fewer good customers refused, which is often the larger hidden cost.
Analyst throughput
Reason codes and linked-entity context cut the time spent reconstructing what happened.
Regulatory defensibility
Explainable decisions with a retained audit trail, which opaque scoring cannot provide.
How it fits into your product
How it embeds
- Synchronous scoring with a hard latency budget, typically under 100ms at the 99th percentile
- Shadow mode so you can run it alongside your current system and compare before switching
- Feedback endpoint so confirmed outcomes continuously improve calibration
- Case management integration pushing flagged events into your existing review queue
- Deployment inside your infrastructure where transaction data cannot leave
- Simulation endpoint to test configuration changes against historical traffic before release
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
How fast is it really?
The design target is under 100ms at the 99th percentile including network time, and that constraint shapes the architecture — feature stores are precomputed and the model is kept small enough to serve synchronously. If your budget is tighter, say so during discovery because it changes the design.
How much history do you need?
Ideally twelve months of transactions with confirmed fraud outcomes. Six is workable. Below that we would start with a rules-led configuration and move to a model as outcomes accumulate, rather than training something unreliable and presenting it as a model.
Can we keep our existing rules?
Yes, and you usually should. Rules encode policy decisions and regulatory requirements that belong in rules. The model handles the patterns nobody has written down. They are evaluated together and reported separately.
What about explaining declines to customers?
Every score carries reason codes, and we generate a customer-safe message alongside the analyst-facing detail. The two are deliberately different: the customer message avoids disclosing detection logic that would help an attacker.
Does transaction data leave our systems?
Not for most deployments. Banks and processors almost always run this inside their own infrastructure, and the design assumes that.
Related blueprints
Chargeback Prediction API
Dispute risk scores at authorisation and afterwards, so a chargeback can be prevented rather than fought six weeks later.
Synthetic Identity Detection API
Flags applications where the identity elements do not cohere, using relationship and consistency signals rather than a single identity check.
Business Verification API
Company registry data, officer and ownership checks and entity resolution, returned as one call your onboarding flow can make.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.