Do we have to change our existing payment flow?

Not by much. It starts as a single decision call placed before the authorization request. At first nothing is blocked and only the score is recorded, so the rules are validated against real traffic; blocking and step-up authentication switch on once the false-positive level is known.

Can we keep our current PG contracts?

Yes. We usually design the integration and operating procedures around the contracts already in place, and when fee or settlement-cycle terms change, only the reconciliation rules need to be re-aligned.

How are security and compliance handled?

By default we store no card data and use provider tokens instead. Data retention scope and access rights are defined at design time, and processing records and access logs are kept as the evidence each standard requires.

Who operates it after the build?

You can run it in-house, jointly, or hand it to us. In every case you receive the reconciliation rules, the incident runbook, and the provider escalation contacts, so the procedure survives a change of owner.

When can settlement differences be explained?

We configure reports and detection rules to explain differences at T+1. Transaction states for authorization, cancellation, refunds, and settlement are aligned with reconciliation rules so the origin of a difference can be traced.

Which permissions are needed when operations are delegated?

Read access comes first. Transaction views, logs, and provider administration are opened only to the scope needed for intake and diagnosis. Refund execution and rule-change permissions are assigned after approval procedures are defined.

How are scope and duration decided?

We share the findings from the first stage, then agree scope and schedule on that basis before delivery. A finished request for proposal is not required: the current environment and the outcome you want are enough to start.

Fraud Detection

A risk response service that puts a decision in front of payment authorization, catching card testing and coupon abuse on the service side.

Payments
Integration
Operations
Risk response

Inquire about a project Get the service brief

01Overview

Service overview

Fraud Detection turns payment and account signals into a risk decision, then splits the response between blocking, step-up authentication, and review. Signals from accounts, devices, and payment behaviour feed the decision. What it covers is the abuse that surfaces only inside your own service.

02Who it fits

Where it fits

Services facing card testing or promotion abuse

Signals are organized by attack pattern, and the rules are in place before the promotion opens.

Teams whose rules reject too many legitimate customers

Rejected transactions are read back to narrow the conditions, and outright blocking gives way to step-up authentication.

Operations teams feeding review outcomes back into detection

Review decisions are kept as rule history, and score thresholds are reset on every tuning cycle.

03What we deliver

Scope of delivery

Risk signals and rule design

The signals available at sign-up, login, and payment are organized into decision rules. What counts as risky is drawn from your own transaction history rather than lifted from an industry template.

Real-time scoring and intervention

A risk score is calculated at transaction time and routed to approval, step-up authentication, or hold. Suspicious transactions are not all refused; the path that verifies one and lets it through is built alongside.

Review and feedback operations

The review screen, the decision criteria, and the time limit for held transactions are set together. Outcomes travel back into the rules, so the same pattern stops piling up in the queue.

Service brief

One page covering scope and the deliverable at each stage.

Get the service brief

How the service works

From transaction signals to risk decisions and review

Connect account, device and payment signals to decision rules, then use review outcomes to refine those rules.

How the service works

Define transaction risk signals
Route to blocking, verification or review
Feed reviews back into rules

04Why this way

Points of difference

Each point lists the deliverable that backs it.

Where the decision sits comes from integration work

Whether the decision call belongs in front of the authorization request or behind it in post-hoc review depends on the payment method. Domestic and overseas payment paths have both been integrated here, so where a cancellation and a refund diverge is already known and the rules are laid on top of that. Digital goods, shipped goods, and bookings each show abuse in their own shape, so items such as how often the delivery address changed or whether the item is consumed immediately go into the rules as well.

Backed by

Transaction state map and RACI
Integration spec and exception design

Client work · Artist platform

Artist platform, company A — point top-up and management

Top-up, spending, and balance were settled into one state model and attached to the running service.

Learn more

False positives are priced into the same table as the loss

Turn the blocking up and losses fall, but good customers leave with the fraud. For each rule, the number of transactions it caught, the share of those confirmed fraudulent, and the review time it consumed are laid side by side before a threshold moves. The cost of stopping a legitimate transaction is on the same table, so no decision comes out of a single column.

Backed by

Reconciliation rules and runbook
Settlement report template and anomaly rules

Client work · AI character chat

AI character chat, company M — payment integration

Authorization, cancellation, and refund states were fixed first, and the provider was connected on top of them.

Learn more

05How to start

From first call to kickoff

Every stage ends with an agreed scope and a deliverable in your hands.

Step 01

Map the transaction

We write out every transaction state and its owning team from authorization through cancellation, refund, and settlement in one state map.

DeliverableTransaction state map and RACI

Step 02

Integrate safely

We build the APIs, security, and data flows assuming failure, retry, and duplicate authorization, then verify them in the sandbox.

DeliverableIntegration spec and exception design

Step 03

Operate and reconcile

We join monitoring, exception handling, and reconciliation into one loop and classify the cause of any anomaly on the day it occurs.

DeliverableReconciliation rules and runbook

Step 04

Stabilize settlement

We hold the closing cycle and fix the report format and anomaly rules so every difference can be explained at T+1.

DeliverableSettlement report template and anomaly rules

06Contract options

Ways to work together

Remote delivery
Fixed price
Subscription

07Service levels

Service levels

Same day

Suspicious transactions traced to cause

T+1

Settlement reconciliation report

3routes

Domestic PG, wallets, and overseas payments

08Example engagements

Client work and example engagements

Work we took on, plus example engagements where we have no case yet.

All client work

A promotion period where tightening rules in a hurry catches real customers

Assume a promotion opens and new accounts and low-value transactions surge together. Turning the blocking rules up in a hurry would catch legitimate customers with them.

Example approachAccount, device, and payment signals are combined to record scores first, and a path is built for review outcomes to return into the rules.

Intended directionSuspicious transactions are triaged on one standard while customer friction stays controlled.

Artist platform, company A — point top-up and management

The platform needed a way to top up and manage the points used in artwork transactions.

What we doTop-up, spending, and balance were settled into one state model and attached to the running service.

What it leavesTransactions that move on points rather than a payment method sit in the same record.

AI character chat, company M — payment integration

A service built with generative tooling had to take payments for the first time.

What we doAuthorization, cancellation, and refund states were fixed first, and the provider was connected on top of them.

What it leavesIt went into operations with no transaction left in an unknown payment state.

09FAQ

Frequently asked questions

Not by much. It starts as a single decision call placed before the authorization request. At first nothing is blocked and only the score is recorded, so the rules are validated against real traffic; blocking and step-up authentication switch on once the false-positive level is known.
Yes. We usually design the integration and operating procedures around the contracts already in place, and when fee or settlement-cycle terms change, only the reconciliation rules need to be re-aligned.
By default we store no card data and use provider tokens instead. Data retention scope and access rights are defined at design time, and processing records and access logs are kept as the evidence each standard requires.
You can run it in-house, jointly, or hand it to us. In every case you receive the reconciliation rules, the incident runbook, and the provider escalation contacts, so the procedure survives a change of owner.
We configure reports and detection rules to explain differences at T+1. Transaction states for authorization, cancellation, refunds, and settlement are aligned with reconciliation rules so the origin of a difference can be traced.
Read access comes first. Transaction views, logs, and provider administration are opened only to the scope needed for intake and diagnosis. Refund execution and rule-change permissions are assigned after approval procedures are defined.
We share the findings from the first stage, then agree scope and schedule on that basis before delivery. A finished request for proposal is not required: the current environment and the outcome you want are enough to start.

11Related insights

Contact us

Tell us your current environment and target outcome, and our team will review it and reply.

Direct line

Phone lines are open weekdays 09:00–18:00

ServiceFraud Detection

Collection and use of personal information

Purpose · Responding to and following up on this inquiry
Items · Name, company, work email, message, visit source (first page visited, referring site domain, campaign parameters)
Retention · 36 months from the date consent is given