Platform
A payment risk infrastructure layer, not a scoring API and not a security product. It takes a mirrored, tokenised event stream and returns multidimensional intelligence with reason codes, graph context and a tamper-evident record.
Sentinel Engine
Each dimension is returned on its own, scored 0 to 100, with the contributions that produced it. They are never summed. The recommendation comes from a fixed ladder that rules can only raise; tenants shape behaviour through rules and permitted actions.
How sure the institution is about who is acting.
Institution-supplied KYC level and authentication strength. Kept deliberately separate from behaviour: a genuine customer can still be defrauded.
Signs the account is no longer in its owner's hands.
Recent SIM, device, authentication-factor and recovery changes, and failed-login bursts, within a 72-hour window.
Signal-level today; a fuller account-takeover engine is planned.
Patterns of a customer being manipulated into paying.
Large first payment to a new recipient, recent recovery, recipient scam signals, low-assurance channel with an outlier amount.
Is this payment unlike the sender's own history?
Amount against the sender's median and spread, first-time recipient, hour profile, fragmentation, rapid dispersal, new-beneficiary concentration, channel.
What is happening on the receiving side.
Receiving velocity, unique senders, first-time-sender ratio, rapid forwarding or cash-out, account age, decayed shared signals, case links.
Accounts that collect from strangers and pass it on.
Many unrelated senders, pass-through retention, dormant-then-explosive inflow, shared device or agent.
Proximity to fraud the institution has confirmed.
Hops to the nearest confirmed case, weighted by evidence tier, and cases within four hops. Large hubs are not walked through.
Is the API client behaving like itself?
New route, source network, credential or permission against established history; velocity, value, recipient fan-out, unfamiliar destinations, time of day, errors.
Cash-out points that behave unlike their cohort.
Cohort-relative cash-out concentration, inflow-to-cash-out delay, splitting, after-hours activity, links to fraud.
Assessed through the agent endpoint and the operator path rather than on every transaction.
Merchant-side abuse and collusion.
Merchants are already a node type in the graph so relationships accumulate; a merchant behavioural baseline and a merchant risk endpoint are not built.
Insider and privileged-access anomalies.
ControlGraph detectors: privileged actions outside established hours, functions or devices; authentication factors shared by privileged users; approver independence.
A detector library. It is not part of a transaction decision and does not sit on the event-stream path.
The multidimensional risk engine.
Scores every transaction on separate dimensions, each with reason codes, and returns a recommendation from a fixed ladder: allow, monitor, warn, step-up, manual review, hold, block, isolate integration. Baselines are judged only on established history, so an intruder cannot teach the engine that a burst is normal while carrying it out. Rules can raise severity; a versioned rules DSL supports simulation and rollback.
Implemented and testedBehavioural baselines for API clients, credentials and source networks.
Routes, sources, credentials, permissions, value, velocity, recipient fan-out, time of day and error patterns are judged per integration against its own history. Integration-level recommendations are capped by the tenant's integration policy, and a compromised integration is a first-class outcome rather than a side effect of transaction scoring.
Implemented and testedsyn_api_partnersyntheticpayouts, permission payouts:createbulk:payoutspayouts:approveRelationships between accounts, devices, agents, integrations and cases.
Stored proximity to confirmed fraud cases, shared device and agent relationships, forward flow tracing to the cash-out point, and tokenised neighbourhood export for investigators. Hubs, such as a large merchant or a busy agent, are never walked through, so popularity is not guilt.
Implemented and testedDetectors for insider and privileged-access anomalies.
Privileged actions outside established hours, functions and devices; authentication factors shared between privileged principals; approver independence for four-eyes flows. A library that institutions feed from their own control events; it is not on the transaction path.
Implemented and testedNo action model exists for principals: the output is a review signal.
control_risk is not part of a transaction decision; it is assessed per principal and reported. Nothing was acted on.
The receiving side as a first-class subject.
Recipient velocity, unrelated-sender concentration, pass-through retention, dormant-to-explosive inflow, rapid forwarding and cash-out, shared devices, and links to confirmed cases. Recipient and mule scores are returned separately and are visible on the sender's decision.
Implemented and testedA tamper-evident record of what the engine saw and said.
Serialised, hash-chained, signed appends; stored anchors checked on every full verification; incremental background verification; key rotation recorded in the chain; export with offline verification; a recovery drill. Verification never passes by omission.
Implemented and testedKey custody in this release is pilot grade: signing keys are passphrase-encrypted files on a volume. The KMS/HSM provider abstraction exists and is tested against a test double only; no production KMS/HSM or WORM object store has been selected.
Confirmation-to-action across institutions, without moving money.
The intended design: when a participant confirms a case, connected entities under other participants' control are surfaced to them as tokenised response alerts with the relationship path, timing and evidence tier; they record their own action. Where a scheme has its own recall mechanism, ResponseNet feeds it rather than duplicating it.
Planned — not builtThe data model and rules exist; no cross-institution traffic runs. Activation requires regulatory review in each jurisdiction.
Operating modes
Opening ADVISORY or ACTIVE requires, at minimum, an external penetration test that has not yet been commissioned. See security and trust.
Scores and records; the applied action is always allow. The recommendation is preserved for measurement. The pilot mode.
As SHADOW, with the institution's operators watching alerts and status in the open.
Recommendations returned as advice. Not production-enabled: a production tenant cannot be configured to it; the gate is a code constant CI checks.
Recommendations applied as decisions, capped by permitted actions. Not production-enabled, and subject to each jurisdiction's automated-decisioning rules.