Demonstration
Synthetic demonstration dataSeven scenarios through the real engine
Every number on this page was produced by Sentinel Engine 0.2.0 running the released code paths on synthetic demonstration data: invented actors, invented transfers, a fictional currency. The input is made up. The output is what the engine actually returned.
Not a live system, not production data, no fraud prevented. The demonstration shows mechanics: how dimensions separate, how reason codes read, how a sequence escalates, how the evidence record is verified. Metrics describe the engine on its own synthetic corpus and say nothing about performance on real data.
Explore the scenarios
Scenario A · SHADOW
Normal activity
What happened (synthetic): A long-standing customer pays a peer an ordinary amount at an ordinary hour; a normal integration initiates an ordinary payout from its usual network.
peak over the scenario's decisions (max per dimension, union of reasons, strongest recommendation).
Scenario B · SHADOW
Mass fan-out
What happened (synthetic): One source that has paid the same six peers for a month suddenly sends 14 similar amounts to 14 recipients it has never paid, within five minutes. Two of those recipients were paid by a wallet the institution confirmed as fraudulent ten days earlier.
peak over the scenario's decisions (max per dimension, union of reasons, strongest recommendation).
FIRST_TIME_RECIPIENTfirst payment ever to this recipientMULE_NEAR_FRAUD_CLUSTERwithin two hops of a confirmed caseNEW_BENEFICIARY_CONCENTRATIONnearly every recipient is one the source had never paidRAPID_RECIPIENT_DISPERSALunusual number of distinct recipients within ten minutesRECIPIENT_CONNECTED_TO_CONFIRMED_CLUSTERrecipient is within two hops of a case the institution confirmedRECIPIENT_FRAUD_PROXIMITYrecipient is close to a confirmed case in the graph
| Transfer | Transaction risk | Recommended |
|---|---|---|
| 1 | 10 | ALLOW |
| 2 | 10 | ALLOW |
| 3 | 10 | ALLOW |
| 4 | 10 | ALLOW |
| 5 | 22 | ALLOW |
| 6 | 22 | ALLOW |
| 7 | 22 | ALLOW |
| 8 | 22 | ALLOW |
| 9 | 53 | STEP_UP |
| 10 | 55 | STEP_UP |
| 11 | 57 | STEP_UP |
| 12 | 57 | STEP_UP |
| 13 | 57 | STEP_UP |
| 14 | 57 | STEP_UP |
Scenario C · SHADOW
Mule network
What happened (synthetic): Three accounts, created recently and sharing one device, each receive from ten unrelated senders within twenty minutes. Two forward most of it to one collector within minutes; the third cashes most of it out at one agent. Then a new victim pays one of the mules.
peak over the scenario's decisions (max per dimension, union of reasons, strongest recommendation).
FIRST_TIME_RECIPIENTfirst payment ever to this recipientMULE_DORMANT_TO_EXPLOSIVEno inflow history, then a burstMULE_PASS_THROUGHmany senders, almost nothing retainedMULE_RAPID_CASH_OUTmost of the inflow cashed out within the hourMULE_SHARED_DEVICEdevice shared with other mule-like accountsMULE_UNRELATED_SENDERSsenders unrelated to the recipientRECIPIENT_FIRST_TIME_SENDER_CONCENTRATIONthose senders had never paid this recipient beforeRECIPIENT_MANY_SENDERS_1Hrecipient collected from many distinct senders in an hourRECIPIENT_NEW_ACCOUNTrecipient account is days oldRECIPIENT_RAPID_FORWARDINGrecipient forwards nearly everything it receivesRECIPIENT_SHARES_DEVICErecipient shares a device with other accountsSCAM_PATTERN_NEW_RECIPIENT_MANY_VICTIMSa new recipient collecting from many first-time senders
syn_victim_c_0_0→syn_mule_1→syn_wallet_collector→syn_agent_7| Recipient | Recipient risk | Mule risk | Mule reasons |
|---|---|---|---|
syn_mule_1 | 69 | 85 | MULE_PASS_THROUGH, MULE_UNRELATED_SENDERS, MULE_DORMANT_TO_EXPLOSIVE, MULE_SHARED_DEVICE |
syn_mule_2 | 90 | 85 | MULE_PASS_THROUGH, MULE_UNRELATED_SENDERS, MULE_DORMANT_TO_EXPLOSIVE, MULE_SHARED_DEVICE |
syn_mule_3 | 69 | 80 | MULE_UNRELATED_SENDERS, MULE_RAPID_CASH_OUT, MULE_DORMANT_TO_EXPLOSIVE, MULE_SHARED_DEVICE |
Scenario D · SHADOW
Compromised integration
What happened (synthetic): An API client that has made ten payouts a day for a month from one network suddenly, at 03:00, sends 40 payouts of 2,000 XTS (its usual is under 100) from a network never seen, to 40 recipients it has never paid — and then calls a function it has never used.
peak over the scenario's decisions (max per dimension, union of reasons, strongest recommendation).
AMOUNT_OUTLIERamount far above the sender's own historyFIRST_TIME_RECIPIENTfirst payment ever to this recipientFRAGMENTED_TRANSFERSvalue split into many similar piecesINTEGRATION_ABNORMAL_TIMEan hour this integration has never been activeINTEGRATION_ABNORMAL_VALUEamounts far above this integration's usual valueINTEGRATION_NEW_SOURCE_NETWORKrequests from a network this integration has never usedINTEGRATION_RECIPIENT_FAN_OUTfar more distinct recipients per hour than this integration's historyINTEGRATION_UNFAMILIAR_DESTINATION_CLUSTERnearly every recipient is new to this integrationNEW_BENEFICIARY_CONCENTRATIONnearly every recipient is one the source had never paidRAPID_RECIPIENT_DISPERSALunusual number of distinct recipients within ten minutesSCAM_PATTERN_LARGE_TO_NEW_RECIPIENTa large amount to a recipient never paid beforeUNUSUAL_TIMEan hour the sender has never been active
| Transfer | Integration risk | Recommended |
|---|---|---|
| 1 | 55 | STEP_UP |
| 5 | 55 | HOLD |
| 10 | 55 | BLOCK |
| 20 | 55 | BLOCK |
| 30 | 100 | HOLD |
| 40 | 100 | HOLD |
Scenario E · SHADOW
Insider / privileged behaviour
What happened (synthetic): An operations lead who has approved payments and reviewed cases from one workstation, in office hours, for a month, changes transfer limits at 02:30 from a workstation never seen. Separately, two payment approvers turn out to share one authentication factor and one device.
APPROVERS_SHARE_INFRASTRUCTUREtwo approvers share a device or factorAUTH_FACTOR_SHARED_BY_PRIVILEGED_USERSone authentication factor serves several privileged principalsPRIVILEGED_ACTION_NEW_DEVICEa workstation this principal has never usedPRIVILEGED_ACTION_NEW_FUNCTIONa privileged function this principal has never usedPRIVILEGED_ACTION_OUTSIDE_HOURSprivileged action at an hour never seen for this principal
- Established
- 60 actions in history
- Anomaly
- change_limits at 02:30 UTC from syn_ws_unknown
- Privilege
- 80
- Auth topology
- 40
- Approvers
- 50
control_risk is not part of a transaction decision; it is assessed per principal and reported. Nothing was acted on.
Scenario F · SHADOW
Authorised scam pattern
What happened (synthetic): A fully verified customer, authenticated with MFA, personally sends 1,500 XTS (forty times her usual) over USSD to an account created this week that has collected from twelve first-time senders in the last hour.
peak over the scenario's decisions (max per dimension, union of reasons, strongest recommendation).
AMOUNT_OUTLIERamount far above the sender's own historyFIRST_TIME_RECIPIENTfirst payment ever to this recipientHIGH_VALUE_LOW_ASSURANCE_CHANNELhigh value over a low-assurance channelMULE_DORMANT_TO_EXPLOSIVEno inflow history, then a burstMULE_UNRELATED_SENDERSsenders unrelated to the recipientRECIPIENT_FIRST_TIME_SENDER_CONCENTRATIONthose senders had never paid this recipient beforeRECIPIENT_MANY_SENDERS_1Hrecipient collected from many distinct senders in an hourRECIPIENT_NEW_ACCOUNTrecipient account is days oldSCAM_PATTERN_LARGE_TO_NEW_RECIPIENTa large amount to a recipient never paid beforeSCAM_PATTERN_NEW_RECIPIENT_MANY_VICTIMSa new recipient collecting from many first-time senders
identity_trust is the institution's assurance about WHO is acting (KYC FULL, MFA): it is high because the genuine customer is acting. The other dimensions describe WHAT is happening and TO WHOM: they are judged separately and never summed.
Scenario G · SHADOW
Lifecycle correctness
What happened (synthetic): One transfer is reported three times (created, authorized, settled) and the settled report is delivered twice. A second transfer is created and then reversed.
No transaction dimensions: this scenario exercises ingestion only.
| Transfer | Reports | Final state | Effective movement | Counted once |
|---|---|---|---|---|
SYN-G-1001 | CREATED (counted) → AUTHORIZED (progressed) → SETTLED (progressed) | SETTLED | 200 of 200 | yes |
SYN-G-1002 | CREATED (counted) → REVERSED (negated) | REVERSED | 0 of 150 | yes |
Replay of the synthetic corpus
Replayed as a partner’s history would be
The same corpus through the replay engine with the label-leakage guard. Recall below one half is deliberate: 48 labelled frauds are planted below the engine’s default thresholds so the report has something honest to say. One candidate investigation cluster (37 entities, 36 alerted transactions) with status CANDIDATE_INVESTIGATION_CLUSTER: never called fraud.
Run it yourself
Design partners receive the engine repository and reproduce this page’s numbers with one command at the reference seed. The demonstration also performs a signed HTTP round trip with request signing and replay protection, omitted here.