Use case 05
Compromised payment integrations
An API credential that stops behaving like itself.
syn_api_partnersynthetic- —About ten payouts a day
- —Business hours only
- —One known source network
- —Usual value under 100 XTS
- —Ordinary recipient spread
- —Route
payouts, permissionpayouts:create
- !Requests from a network never seen
- !40 payouts to 40 recipients it has never paid
- !2,000 XTS each, far above its usual value
- !An hour this integration has never been active
- !Novel route
bulk:payouts - !Unexpected permission
payouts:approve
The problem
Payment platforms expose payout and transfer APIs to partners and internal systems. A leaked credential or a compromised partner does not look like a customer; it looks like an integration doing something it has never done.
How Cenvoriq approaches it
Integration Risk is its own dimension, and integration-level recommendations, up to isolating the integration, are capped by the tenant's integration policy. Baselines are judged on established history so the burst cannot normalise itself.
Status in the current release
Built and tested; shown in demo scenario D, where forty 03:00 payouts from a new network reach an isolate-integration recommendation and a never-used permission is flagged.
- New route, source network, credential or permission
- Amounts far above the integration's usual value
- Recipient fan-out to accounts never paid
- Activity at hours never seen for this integration
- Error-rate change
Deployment
Measured in SHADOW before it touches a payment
A design partner replays its own tokenised history first, then mirrors a live stream. The engine scores this pattern and records the recommendation; the applied action is always allow and the institution’s own systems keep every control.