Cadre reference capture
A recorded path through an illustrative case.
Observed path
Get payment
Get baseline
Get device
Check beneficiary
3 more recorded steps in the full record.
Committed the contracted outcome
Fraud · Example
Payment fraud routing
Cadre name · Tripwire
Routes a payment to allow, step-up, hold, or block using distinct fraud and scam risks.
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
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-recurringNew device + impossible-travel geo + session anomaly, draining to a new high-value beneficiary. Third-party fraud
block.
Case key
account-takeoverCustomer's own device, but urgency + first-time near-max payee + investment memo + coaching. APP scam
hold + customer-facing intervention.
Case key
app-investment-scamKnown payee, unusual size
a large completion-funds payment to a known solicitor from a recognized device, with no scam signal. The payment is genuine; allow is the disciplined call, and a block here is the costly error.
Case key
legit-unusual-known-payeeHidden mule network
an ordinary-looking marketplace payment whose beneficiary is reused across 17 customers with a high mule score. The shared destination outweighs the clean memo and device; hold or refer is the disciplined call.
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.
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
Institution-specific validation
These questions shape how the example fits an institution.
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 examples
Related examples
Related examples