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
Screening
The beneficiary and, where applicable, the sending counterparty are screened before any funds move.
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.
4
Rail submission
A payout that clears every check moves to
approved and is queued for the rail. From here, processing → sent → completed are rail-driven and reflect settlement reality.on_hold: true, and Anton does not say why. A review ends with the payout continuing, being cancelled, or moving to cannot_be_processed.
The payout state machine
manual_review, screening_failed, pending_engine_review) returns to the flow, is cancelled, or moves to cannot_be_processed when the review concludes. A payout can also be placed on hold in another pre-rail status; on_hold tells you, whatever the status.
Every transition emits a 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. Treat a review as a normal state. Most legitimate payouts clear review in minutes. When a payout showson_hold: true, surface a pending state to your end user; do not surface an error. A payout on hold cannot be cancelled until the review concludes — the cancel request returns 409 payout_on_hold.
Respond to RFIs promptly. If Anton needs more information during a review — a beneficiary’s incorporation document, proof of source of funds — an rfi.created event fires. A team member with the rfis.respond permission (held by the Admin and Operator roles) responds in the dashboard and can attach documents to the response. RFI responses are accepted from signed-in dashboard users only, not from API credentials. The payout cannot clear review until the RFI is closed.
Don’t retry a cannot_be_processed payout. Creating a new payout to the same beneficiary does not change the outcome.
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.