Conclusion Policies: Timing and KYC

1) Why formalize the policy of conclusions

• reduces the level of tickets and escalations ("when will the money come? »);
• ensures AML/KYC compliance (age, sanctions, SoF/SoW);
• reduces fraud/chargeback and arbitration disputes;
• gives predictable SLAs for finance/support/marketing.

2) Rail classification and expected speed

3) KYC levels and impact on conclusions

Principle: the higher the KYC, the wider the available rails and higher the limits/speed.

Basic: small limits; only "slow" or internal pins are allowed (per wallet/limited A2A).
Full KYC (ID + Address + Liveness): standard limits; access to bank rails, Push-to-Card, local fast schemes.
EDD (extended): large amounts/frequent payouts; requires SoF/SoW (source of funds/status), recipient whitelists, expedited processing.

Step-up triggers: large amount, new recipient, atypical device/geo, excess velocity, high-risk MCC (iGaming, quasi-cache), accumulated winnings.

4) Limits and anti-fraud on leads

• Per-transaction / Daily / Weekly / Monthly caps.
• Velocity: N payments/hour, sliding window amounts, frequency of changing details.
• New recipients: reduced cap/mandatory cooling-off (for example, 12-24 hours) and step-up.
• Geo/sanctions: deny/allow lists, ban certain countries/banks.
• Risk profile: multipliers of client/session score limits.
• Payout-lock: temporary blocking after anomalies/chargeback/ODR, until verification is completed.

5) Payout statuses and operating model

• 'requested '- user request
• 'queued '- queued payout
• 'processing '- processed by provider/bank
• 'sent '- sent to rail (there is UTR/ARN/Trace)
• 'settled '- recipient cleared/no Finrisks
• 'failed '- rail/bank failure
• 'reversed/returned '- refund (ACH R codes, SEPA return, FPS reject)
• 'on _ hold '- compliance/EDD/SoF check
• 'canceled '- cancelled by user/operator

Artifacts: 'payoutId', 'requestId' (idempotency), 'beneficialId', 'rail', 'amount/currency', 'UTR/ARN/Trace', failure codes.

6) Payout queue and kernel architecture

• Orchestrator (state machine): routing on rails/limits/timezones.
• Scheduler: accounting for cut-off/holidays (per-rail/per-country).
• Idempotency: key on 'requestId' + event deduplication.
• Webhooks provider: signed/NMAS, retray with backoff, DLQ.
• Reconciliation: auto-recon by registers (daily) + periodic full-recon; UTR/ARN storage.
• Policy Engine: CCR/limits/scoring rules and causes of failures (explainability).
• Treasury/Liquidity: monitoring of PSP/bank balances, fast rail prefanding, rebalancing.

7) Liquidity and Prefanding

Fast rails (RTP/FPS/PIX/Push-to-Card/e-wallets) often require prefanding.
Keep limits on the provider and auto-rebalance (sweep) between accounts.
Cash gap: Separate the accounting of "promised" payments from actual debits.
Enter an automatic method derating when liquidity falls (temporarily switch to slow rails).

8) Communications and UX

Show expected arrival date/time including rail, cut-off and user TZ.

Explained statuses: "on KYC/SoF check," "waiting for a bank window," "sent: UTR/ARN number."

Product FAQ: Limits, timing, rails supported, what SoF/SoW is, why the request is denied.
New recipients: warning about hold/step-up, confirmation of details (micro-deposit/1-cent check, test payout).

Anti-error UX: IBAN/BIC mask, format validation, BSB/Sort code hint, saving recipient "templates."

Cooldown: Soft latency for high-risk profiles with transparent cause.

9) Compliance: KYC/AML/EDD/SoF/SoW

KYC: ID, address, liveness; age and geo-blocks.
Sanctions/PEP: onboarding and cyclic screening; before large payments - a second check.
SoF/SoW: confirmation of source of funds/condition (bank statements, income statements, contract).
Case-management: decision log, SLA processing, audit-trail.
Responsible Gaming (for iGaming): bonus withdrawal holds, self-exclusion checks, day/week "responsible" limits.

10) Errors and returns on rails (what to consider)

ACH: returns (R01... R10), NACHA windows, block lists.
SEPA: Reject/Return/Recall; IBAN validation, code reason (AC04, AG01, etc.).
FPS/RTP/PIX: usually final; return - a separate counter operation.
Push-to-Card: Issuer may have delays/limit deviations.
SWIFT: correspondent fees, "lifting fees," delays in compliance of the receiving bank.

11) Economics and commissions

Fee model: fix/percentage, thresholds for amounts, FX margin, separate tariffs for fast rails.
KYC-levels ↔ rates: VIP/EDD - below commission/priority; Basic - higher maintenance cost.
Antifraud costs: the cost of inspections/investments, the share of returns/refusals.
Optimization: grouping payments (batch), schedule of "slow" rails in off-peak, rail selection by amount/country/time of day.

12) KPI/metrics for management

SLA compliance:% of payments that arrived on the promised date.
Time-to-Cash: median/95-percentile time to 'settled'.
Return/Reject rate for rails and reasons (codes).
Share by rail: distribution by methods and their approve/settle.
ODR/Delay/Failure Complaints.
Hold/EDD rate: the share of payments that fell into manual verification; average decision time.
Liquidity uptime: time at which fast rails are available.
Cost per payout и FX impact.

13) Conclusion Policy Launch Checklist

1. Rail matrix: countries/currencies/limits/deadlines/cut-off/holidays - in config service.
2. Policy Engine: KYC/limits/velocity/EDD rules with explain logs.
3. Payout orchestrator: queue, retrai, idempotency, webhooks with HMAC.
4. Treasury: fast rail prefanding, auto rebalance, provider limits.
5. KYC/AML/SoF/SoW: providers, playbooks, SLAs, escalations.
6. UX/Communication: ETA by rail, statuses, UTR/ARN, understandable reasons for holds/failures.

7. Recon: daily auto-recon + full-recon; alerts to "success without a registry," "aging payouts."

8. Monitoring: KPI dashboards, liquidity/failure/return growth alarms.
9. Test package: e2e for each rail (success/failure/return), new recipient, large amount, provider timeouts.

14) Policy section template (for ToS/wiki)

• SEPA: T + 1 BD (until 3pm CET), SEPA Instant - usually within 30 minutes.
• FPS/PIX/RTP: usually minute mode, but checks up to 24 hours are possible for new recipients.
• ACH: T+1–T+2 BD; Same Day ACH - when serving before the cut-off bank.

• Up to € X/day - Basic, over - ID + selfies required; over € Y - SoF/SoW.
• New recipient - up to 24 hours safe hold.

• Per-txn: …, Daily: …, Weekly: … (dynamically by level/risk).

• SEPA/FPS — …, SWIFT — … (+ correspondent fees), Push-to-Card -....

• In the case of Reject/Return, the funds will return to the balance within...; we will inform you about the reason in the notification (code/description).

15) Quick answers for support

When will the money come? - For {rail} expect until {ETA}. Your UTR/ARN is {code}.
Why hold? - Security rules have been triggered (new recipient/amount/geo). Please download the document {SoF/ID}.
Is it possible faster? - On {fast rail} you will need a prefanding/other limit; suggest an alternative method.
Why refusal? - The recipient's bank rejected (code {X}). Check details or select another rail.

Summary

Strong inference policy = transparent timing + predictable KYC limits + reliable rail orchestration. Store rules in a config, use a policy engine with explain logs, ensure idempotency/Recon/Webhooks, manage liquidity and prefanding, and communicate with the user the exact ETA + UTR/ARN. So you reduce risk, maintain compliance and increase trust without sacrificing the speed of payments.