POST /v1/payouts is not submitted to a rail immediately. Anton evaluates it first. The evaluation outcome is reflected in the payout’s state — your application reads that state (and the webhook events that announce transitions) to decide what to do next.
What runs on every payout
1
Sanctions screening
The beneficiary and, where applicable, the sending counterparty are checked against OFAC, EU, UK, UN, and other consolidated sanctions lists. A hit moves the payout to
screening_failed — it will not be submitted.2
Velocity evaluation
Anton applies merchant-scoped velocity rules: daily and monthly caps, geographic limits, instrument-level thresholds. Exceeding a rule moves the payout to
velocity_blocked.3
Risk scoring
The Anton Engine evaluates the payout against cross-merchant trust signals, beneficiary history, counterparty reputation, and real-time anomaly detection. A sufficiently risky payout moves to
manual_review for a human decision.4
Rail submission
A payout that clears all three checks moves to
approved and is queued for the rail. From here, processing → sent → completed are rail-driven and reflect settlement reality.The payout state machine
payout.* webhook event. Every transition is recorded in the audit log.
What each terminal state means
What your integration should do
Subscribe to webhooks. Do not poll. The payout lifecycle is event-driven. Polling wastes rate-limit budget and misses transitions. Treatmanual_review as a normal state. Most legitimate payouts clear review in minutes. Surface a pending state to your end user; do not surface an error.
Respond to RFIs promptly. If a payout enters manual_review and Anton needs more information — a beneficiary’s incorporation document, proof of source of funds — an rfi.created event fires. Your merchant responds through the dashboard. The payout cannot clear review until the RFI is closed.
Never retry a screening_failed payout with the same beneficiary. It will fail again. Either correct the beneficiary’s details or stop attempting to send to them.
What you can and can’t control
Screening, velocity, and engine evaluation run automatically on every live payout. You cannot disable them, override them at submission time, or skip them with a flag. This is a compliance requirement, not a limitation. For select merchants, Anton can enable programmatic access to the engine — risk signals, velocity rule management, and dashboard-equivalent views — on top of the public API surface. These are not part of the public v1.0.0 contract; they’re negotiated per account. Contact us if you want to inspect or tune risk signals programmatically.What you send changes what Anton can see
Anton scores what it is given. The largest single improvement most integrations can make is sending thesession object on POST /v1/payouts — the end-user IP, timezone, and
user agent your own edge observed.
Without it the only address in the request is your server’s, so network- and
location-based reasoning has nothing to work with. With it, Anton can check the payer’s
country against the destination corridor, test whether the browser’s timezone agrees with
where the address resolves, and tell residential traffic apart from datacenter, Tor, or
relay egress.
Every field is optional and none of them can fail a payout — invalid values come back as
session_quality warnings, not errors. See
Send end-user session context.