Fraud · Agent pack

New pack

Payment fraud routing

Cadre pack · Tripwire

Routes a payment to allow, step-up, hold, or block using distinct fraud and scam risks.

Demonstrated on representative cases. Source coverage, thresholds, policy interpretation, escalation design, and performance require institution-specific validation.

Operating dossier

The job, permitted decisions, and owner

Mandate

Evaluates payments on the authorization path and returns allow / step-up / hold / block, separating third-party fraud from authorized-push-payment scam risk.

Case arrives with: Payment ID
Allowed outcomes: Allow · Step Up · Hold · Block
Where it fits: Fraud & Disputes

Operating logic

01Applies an allow, step-up, hold, or block decision on the payment rail.
02Scores third-party fraud and authorized-push-payment scams as two separate risks, because they call for opposite responses.
03In the illustrated policy, account-takeover evidence can route to block while coached-customer indicators route to a hold and customer intervention; an accountable owner sets the live thresholds and release authority.
04Guards against over-blocking explicitly: size alone does not become a fraud signal when the payee, device, and other supplied context are consistent with prior activity.
05Records structured reason codes with every decision so the oversight desk can audit exactly which signals drove it.

Decision logic

01Applies an allow, step-up, hold, or block decision on the payment rail.
02Scores third-party fraud and authorized-push-payment scams as two separate risks, because they call for opposite responses.
03In the illustrated policy, account-takeover evidence can route to block while coached-customer indicators route to a hold and customer intervention; an accountable owner sets the live thresholds and release authority.
04Guards against over-blocking explicitly: size alone does not become a fraud signal when the payee, device, and other supplied context are consistent with prior activity.
05Records structured reason codes with every decision so the oversight desk can audit exactly which signals drove it.

Must not: Invent missing evidence or act outside the permitted outcomes.
Human owner: Held payments and customer intervention
Evidence retained: Structured outcome, observed path, and the source evidence used.

Case and record

One case, from supplied evidence to recorded decision

Supplied case

Representative case dataSynthetic or simulated data

Payment ID: PAY1

View the case data

Case key normal-recurring

{
  "paymentId": "PAY1"
}

Recorded path and outcome

Cadre reference capture

One frozen, sanitized path through representative data. It is an inspection aid, not a performance claim.

Observed path

Get payment
Get baseline
Get device
Check beneficiary
Assess scam

The full record continues on the capture page.

Recorded outcome

Allow

Decision

Open decision record

Evaluation and limits

Evaluation coverage and stopping points

Published evaluation map

Expected decisions, boundaries, and costly failure modes.

These cases show what the pack is asked to decide, when it should stop, and which plausible errors the evaluation is meant to expose. They are not a reliability score or independent validation.

Expected and borderline behavior

Routine judgments, close calls, and named stopping points.

Usual rent payee, in-baseline amount, known device, no scam signal
allow.
Case key
normal-recurring
New device + impossible-travel geo + session anomaly, draining to a new high-value beneficiary. Third-party fraud
block.
Case key
account-takeover
Customer's own device, but urgency + first-time near-max payee + investment memo + coaching. APP scam
hold + customer-facing intervention.
Case key
app-investment-scam
SAFETY
large completion-funds payment to a KNOWN solicitor on a recognised device, no scam signal. Must NOT over-block.
Case key
legit-unusual-known-payee
ADVERSARIAL: ordinary-looking marketplace payment, but the beneficiary is reused across 17 customers with a high mule score. The benign memo and clean device must not mask the mule destination
hold / refer.
Case key
mule-network-reuse

Operating fit

Workflow placement and validation

Operating pattern

Decide, refer, or stop

Give the pack a short list of permitted decisions and require referral when the evidence cannot support one.

01Receive the case
02Gather named evidence
03Apply the decision rules
04Decide or refer
05Record the decision and owner

Wider workflows

Fraud & Disputes·In-flight fraud routing

Decision sequence and workflow placement

01Receive the case
02Gather named evidence
03Apply the decision rules
04Decide or refer
05Record the decision and owner

Wider workflows

Fraud & Disputes·In-flight fraud routing

Pattern guide

Institution-specific validation

These questions remain open until the pack is fitted to an institution.

Policy and legal interpretation
Source coverage, quality, and freshness
Thresholds and exception calibration
Integration and degraded-mode behavior
Human approval and escalation design
Performance on the institution’s own case mix

Validation questions

Policy and legal interpretation
Source coverage, quality, and freshness
Thresholds and exception calibration
Integration and degraded-mode behavior
Human approval and escalation design
Performance on the institution’s own case mix

Inputs, actions, and outcomes

Give it

Payment ID

It does

Get paymentget_payment
Get baselineget_baseline
Get deviceget_device
Check beneficiarycheck_beneficiary
Assess scamassess_scam
Decidecommitdecide

It returns · Decision

Allow
Step Up
Hold
Block

Related packs

Card dispute adjudication

Also in Fraud & Disputes · Arbiter

Credit application intake

Same Verify before underwriting pattern · Onramp

Sanctions disposition

Same Decide, refer, or stop pattern · Cerberus

Transaction-monitoring triage

Same Triage before investigation pattern · Sift