Fraud intelligence built for the speed of modern payments.
Detect suspicious activity, understand risk, and make more confident transaction decisions with fraud detection infrastructure designed for financial institutions.
Transaction
txn_9x8K2
734of 1000
Risk band High
- Amount
- USD 750.00
- Channel
- ecommerce
- Merchant category
- electronics
- Time
- 03:15 UTC
Why this score
- Model fraud probability exceeded the active decision threshold. Severity: high.
- Transaction amount is high enough to increase loss exposure. Severity: medium.
- Transaction amount is materially above the observed baseline. Severity: medium.
- Transaction occurred during a higher-risk overnight window. Severity: low.
Fraud intelligence infrastructure for institutions that move money.
Remorant sits beside your payment flow. It receives a transaction, returns a score and a recommended decision, and keeps the record your risk and audit teams will ask for later.
- Banks
- Score card and account payments before authorization, and give fraud operations one queue for the transactions that need a person.
- Payment processors
- Add a risk score and reason codes to the transactions you route, with thresholds set separately for each tenant.
- Fintech platforms
- Integrate through one REST endpoint that accepts ordinary transaction fields, so there are no model features to engineer on your side.
- Card issuers
- Review high-risk card transactions alongside the indicators that raised the score, and record the confirmed outcome.
- Digital banking providers
- Give a small risk team rules, allow and block lists, and alerts, without building the tooling in-house.
- Lending platforms
- Score disbursements and repayments as they are made, and keep a decision record for each one.
Stopping fraud is half the problem. The other half is not stopping good payments.
Fraud attempts keep changing shape, and an authorization decision has to be made in the time it takes a payment to clear. A control that is too loose lets losses through. One that is too tight declines legitimate customers and sends them to a competitor.
Most teams work with risk signals spread across several systems, a review queue that grows faster than headcount, and auditors who expect each decision to be explained after the fact. A score alone does not solve that. The reasoning and the record have to come with it.
$33.83 billion
Card fraud losses worldwide in 2023.
Source: Nilson Report, December 2024
$12.5 billion
Fraud losses reported by US consumers in 2024, up 25% on the previous year.
Source: US Federal Trade Commission, March 2025
£1.17 billion
Stolen through payment fraud in the UK in 2024.
Source: UK Finance, Annual Fraud Report 2025
One platform from the score to the audit file.
Scoring is the start. The same record then moves through policy, review and reporting, so nobody has to rebuild what happened from three different tools.
- Real-time risk scoring
- Each transaction gets a fraud probability, a score from 0 to 1000 and a risk band in a single API call.
- Explained decisions
- Every score carries reason codes with the evidence behind them, written for analysts and support staff.
- Investigation workflow
- A review queue and case files with assignment, notes and status, so flagged payments reach a named owner.
- Transaction monitoring
- Trends, risk distribution and the current high-risk transactions on one dashboard, with alerts.
- Rules and thresholds
- Write and test your own rules, keep allow and block lists, and set the decision threshold per tenant.
- Model oversight
- Versioned models with promotion and rollback, drift monitoring, and an endpoint for sending back confirmed outcomes.
- API integration
- REST endpoints for single and batch scoring, plus signed webhooks to notify your systems.
- Decision history
- Each decision is stored with its ID, model version, threshold and reasons, and can be exported for audit.
The request and response formats are in the developer documentation.
Where Remorant sits in a payment decision.
Remorant recommends. It does not authorize, hold or decline a payment. That decision stays with your institution, in your own systems. You can also score in parallel without acting on the result, and compare the recommendations with what actually happened.
1 of 5Your systems
Transaction received
Your payment or authorization system sends the transaction to the scoring API.
2 of 5Remorant
Signals evaluated
Amount, timing, velocity, merchant and device fields are checked and prepared for the model.
3 of 5Remorant
Risk scored
The model returns a probability. Policy turns it into a score, a band and reason codes.
4 of 5Your systems
Decision returned
You receive a recommendation to approve, review or block. Your system decides what happens to the payment.
5 of 5Remorant
Outcome reviewed
Analysts work the review queue, and confirmed outcomes are recorded against the decision.
The working surface for a fraud team.
Flagged transactions arrive in a queue with their score and leading reason. Each one keeps a history of who did what, from the first score to the confirmed outcome.
Review queue
Demonstration data
| Transaction | Amount | Score | Band | Leading reason | Assigned to | Status |
|---|---|---|---|---|---|---|
| txn_9x8K2 | USD 750.00 | 734 | high | Model score above threshold | K. Owusu | In review |
| txn_7pQ41 | USD 2,400.00 | 921 | critical | Critical risk score | Unassigned | Open |
| txn_3mT80 | USD 310.00 | 412 | medium | Elevated model score | A. Boateng | In review |
| txn_5cR27 | USD 1,000.00 | 388 | medium | Round high-value amount | Unassigned | Open |
| txn_1hV66 | USD 86.50 | 362 | medium | Velocity anomaly | K. Owusu | Resolved |
A score your team can question.
A number on its own cannot be reviewed. Remorant returns the reasoning with it, and is careful about what that reasoning does and does not establish.
- Explanation
- Reason codes state, in plain language, which indicators raised the score for this transaction and the values behind them.
- Interpretation
- Where the model supports it, feature contributions show how much each input moved the score. This describes model behaviour and is not a statement of cause.
- Compliance
- Explanations and decision records support your governance and audit work. They do not make a decision compliant, and Remorant does not claim regulatory approval.
txn_9x8K2, USD 750.00, ecommerce, 03:15 UTC
Fraud probability 0.734, recommended decision block
MODEL_SCORE_ABOVE_THRESHOLDHigh severity
Model fraud probability exceeded the active decision threshold.
fraud_probability 0.734, threshold 0.5
HIGH_TRANSACTION_AMOUNTMedium severity
Transaction amount is high enough to increase loss exposure.
amount 750.0
AMOUNT_ABOVE_BASELINEMedium severity
Transaction amount is materially above the observed baseline.
amount_zscore 3.1
OFF_HOURS_TRANSACTIONLow severity
Transaction occurred during a higher-risk overnight window.
hour_of_day 3
- Decision ID
- dec_5de12db5-6dc0-477b-80bb-e0d13f06116e
- Audit reference
- prediction:5de12db5-6dc0-477b-80bb-e0d13f06116e
- Threshold
- 0.5 (global)
- Review status
- In review
Security controls, stated plainly.
This is what the platform does today. We list controls that are implemented, and we answer security questionnaires and architecture questions directly during an evaluation.
- Access control
- Role-based permissions separate administrators, analysts, read-only users and integration accounts.
- Authentication
- Signed session tokens expire after eight hours, and a user can revoke all of their sessions at once.
- Credential storage
- Passwords are stored as bcrypt hashes. API keys are stored as SHA-256 hashes and shown once, at creation.
- Tenant separation
- Records carry a tenant identifier and requests are scoped to the tenant of the authenticated account.
- Audit logging
- Production scoring requests are written to an audit record with the decision, model version and threshold used.
- Transport and browser security
- Strict transport security, a content security policy and framing protection are set on API and web responses.
- Abuse protection
- Rate limits apply to scoring and authentication endpoints, and request bodies are capped in size.
- Data subject requests
- Access, export and erasure requests are logged and handled through a dedicated workflow.
Built to integrate. Designed to scale.
One request in, one decision out. The example on this page is the real v2 scoring contract.
- Authentication
- Exchange credentials for a bearer token at POST /api/v1/auth/login and send it with each request.
- Scoring
- POST /api/v2/transactions/score takes ordinary transaction fields. POST /api/v1/batch scores many at once.
- Responses
- Probability, score, band, decision, reason codes and audit identifiers come back in one JSON object.
- Errors
- Invalid input returns a 400 with an error code, such as TRANSACTION_SCHEMA_ERROR, and the fields at fault.
- Testing
- A separate sandbox environment and an in-browser playground let you try requests before production.
curl -X POST "$REMORANT_API_URL/api/v2/transactions/score" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"transaction": {
"transaction_id": "txn_9x8K2",
"amount": 750.0,
"currency": "USD",
"transaction_time": "2026-09-02T03:15:00Z",
"channel": "ecommerce",
"merchant": {
"id": "merchant_123",
"category": "electronics",
"country": "US"
},
"customer": { "id": "customer_456", "country": "US" },
"device": { "ip_address": "203.0.113.10" }
}
}'What a risk team should expect to change.
We do not publish detection rates or savings figures here. Results depend on your portfolio, and the place to measure them is a pilot on your own traffic.
- See the risk on every transaction, not only the ones a rule happened to catch.
- Apply the same threshold and policy to every decision, with the source of each threshold on record.
- Send analysts the cases that need judgement, with the reasons already attached.
- Notice a shift in model behaviour or fraud pattern from monitoring, before it shows up in losses.
- Answer "why was this payment flagged?" from the decision record, months later.
How an evaluation with us runs.
These are the stages we propose, at the pace your institution sets. They are not a fixed timeline. Pricing is usage-based and quoted for your volume. Write to hello@whizzonby.com.
Stage 1
Discovery
We learn your payment flows, fraud profile and the controls already in place.
Stage 2
Technical evaluation
Your engineers test the API in the sandbox. We walk through architecture and security questions.
Stage 3
Integration planning
Together we map your transaction fields to the scoring contract and agree where the score is consumed.
Stage 4
Pilot
Remorant scores live traffic alongside your current controls, and both sides review the results.
Stage 5
Production readiness
Thresholds, rules, review workflow and monitoring are agreed before any decision depends on the score.
Build greater confidence into every transaction.
Explore how Remorant can support your institution's fraud detection and risk decisioning strategy.