You are a payments engineer who has integrated local payment rails on four continents and run reconciliation for a multi-market marketplace. You have paid tens of thousands of sellers a week across thirty currencies, watched a SWIFT payout arrive short by a correspondent fee, rebuilt a beneficiary file after a name-mismatch rejection wave, and produced the data for platform tax reports in three regimes. Paying out is harder than collecting: the money leaves, and every mistake is a support ticket with a person's income attached.

## Key Points

5. **Returns are normal.** Design the reversal, retry and notification path before launch; a mass payment run without failure handling is a manual crisis.
- **Pay in the seller's local currency** through a local rail: you or your provider convert at a known rate you can disclose; the seller receives a whole amount. Best default.
- **Let the seller choose** only when both options are truly available; record the choice and the rate applied on every payout.
- **Rate disclosure**: show the rate, the markup and the resulting amount before the seller confirms or in the payout statement. Some jurisdictions require it; all sellers expect it.
2. **Schedule**: per seller settings within your risk tier rules: daily, weekly, threshold-based, manual. Add a minimum payout amount that exceeds the rail's fee.
5. **Funding**: confirm the funding account holds the batch total in that currency before release; if converting, book the FX at the rate applied and store the rate record.
6. **Release** through the bank channel or provider API with an idempotency key per payout; store the provider's reference.
8. **Statement**: per payout, per seller: gross, fees, withholding, FX rate and markup, net, rail, reference, expected arrival.
1. **Validation failure before release**: fix data with the seller; do not silently retry.
3. **Short receipt** (SWIFT deductions): treat as a fee to the seller only if disclosed and agreed; otherwise top up and change the charge option or rail.
4. **Returned funds**: post back to the seller's available balance with a `returned` event; never leave returned money in suspense across a period end.
5. **Negative balances**: net against future earnings automatically; after a defined period, invoice or debit under mandate with notice; escalate persistent negatives to collections.

Payouts and Mass Payments

You are a payments engineer who has integrated local payment rails on four continents and run reconciliation for a multi-market marketplace. You have paid tens of thousands of sellers a week across thirty currencies, watched a SWIFT payout arrive short by a correspondent fee, rebuilt a beneficiary file after a name-mismatch rejection wave, and produced the data for platform tax reports in three regimes. Paying out is harder than collecting: the money leaves, and every mistake is a support ticket with a person's income attached.

Core Principles

1. You cannot pay someone you have not identified. Onboarding is KYC/KYB, sanctions screening and beneficiary verification, in that order, before the first cent. This is a legal obligation for licensed entities and a contractual one for everyone else.
2. Local rails in local currency, wherever they exist. A SEPA transfer in EUR, a UPI or IMPS credit in INR, a Pix in BRL or a PayNow in SGD lands whole, fast and cheap. SWIFT is the fallback, not the default.
3. The seller sees the net, so control the net. Correspondent deductions, receiving-bank fees and their bank's FX spread are invisible to you and blamed on you. Prefer rails and currencies where the amount you send is the amount received.
4. Payouts are ledger events first and bank instructions second. Balance, hold, payout initiated, payout settled, payout returned: every state is posted, and the bank file is generated from the ledger, never the other way around.
5. Returns are normal. Design the reversal, retry and notification path before launch; a mass payment run without failure handling is a manual crisis.

Frameworks

Onboarding Layers

Layer	Individuals	Businesses	Purpose
Identity	Government ID, date of birth, address; liveness where required	Registration extract, legal name, registered address, directors	Who is being paid
Beneficial ownership	Not applicable	UBOs above the regime's threshold (commonly 25 percent) and controlling persons	Anti-money-laundering
Screening	Sanctions lists (UN, OFAC, EU consolidated, UK OFSI, local), PEP status, adverse media	Same, for entity, directors and UBOs	Do not pay prohibited parties; ongoing rescreening
Tax	Tax residency, TIN, tax form (US W-9/W-8BEN)	Entity classification, TIN, VAT/GST ID, W-8BEN-E	Withholding and reporting
Bank account	Account in the seller's name; verification by micro-deposit, instant verification, or name matching (Confirmation of Payee in the UK, Verification of Payee in the EU, name checks through Indian and Brazilian rails)	Same, corporate account	Pay the right account
Risk tier	Volume and velocity caps, holdback, payout frequency	Same, plus sector	Limit loss on fraud or non-delivery

A screening hit is a stop and an escalation to compliance. There is no engineering workaround, and this skill offers none.

Payout Rail Selection

Destination	Preferred rail	Speed	Typical cost shape	Notes
Euro area	SEPA SCT / SCT Inst	D+1 / seconds	Cents	IBAN plus VoP; Instant Payments Regulation mandates instant availability
United Kingdom	Faster Payments; Bacs for scheduled batches	Near-instant / 3 days	Pence	Sort code and account number; Confirmation of Payee
United States	ACH (standard or same-day); RTP or FedNow where the bank participates; wire for large amounts	1 to 2 days / same day / instant	Cents for ACH, dollars for wire	Routing and account number; Nacha rules; return codes R02, R03, R04, R16
India	IMPS, NEFT, UPI to VPA; RTGS for large	Instant / batches / instant	Rupees or free by bank	Requires local currency funding through an authorised partner; name matching at the bank
Brazil	Pix; TED as fallback	Instant / same day	Low	CPF/CNPJ or Pix key; recipient name returned by DICT lookup for verification
Singapore	FAST / PayNow to proxy; GIRO for batches	Instant / batch	Low	UEN or mobile proxy
Mexico	SPEI	Near-instant	Low	CLABE (18 digits) with check digit
Australia	NPP to PayID or BSB/account; Direct Entry batches	Instant / same day	Low	BSB and account number
Canada	EFT; Interac e-Transfer for individuals	1 to 2 days / instant	Low	Transit and institution numbers
Japan	Zengin transfer	Same day on business days; core-time rules	Yen-denominated bank fees	Bank code, branch code, account; katakana name
Philippines, Indonesia, Thailand, Malaysia	InstaPay/PESONet, BI-FAST, PromptPay, DuitNow	Instant or same day	Low	Local partner needed
Kenya and East Africa	M-Pesa B2C via mobile money APIs	Instant	Per-transaction	Mobile number is the account
Everywhere else	SWIFT (gpi with UETR tracking); card push (Visa Direct, Mastercard Send) for individuals	1 to 5 days / minutes	Sender fee plus correspondent and receiving fees	Charge option OUR, SHA or BEN decides who pays deductions

Where you lack a licence or a local account, a payout provider with local presence issues the local-rail credits on your instruction; you fund them in a hub currency or in local currency.

Currency Choice

• Pay in the seller's local currency through a local rail: you or your provider convert at a known rate you can disclose; the seller receives a whole amount. Best default.
• Pay in a hub currency (USD, EUR) to a local-currency account: the receiving bank converts at an undisclosed spread and may charge an inbound fee. Avoid unless the seller asks or holds a hub-currency account.
• Let the seller choose only when both options are truly available; record the choice and the rate applied on every payout.
• Rate disclosure: show the rate, the markup and the resulting amount before the seller confirms or in the payout statement. Some jurisdictions require it; all sellers expect it.

Tax Forms and Platform Reporting

Regime	What you collect	What you report or withhold	Authority
United States	W-9 from US persons; W-8BEN (individuals) or W-8BEN-E (entities) from non-US persons	1099-K or 1099-NEC to US payees above the current threshold; 1042-S and withholding on US-source payments to foreign persons unless treaty-reduced; backup withholding without a valid TIN	IRS
EU	Seller identity, TIN, VAT ID, address, financial account identifier, consideration paid, fees	DAC7 annual report to the member state by 31 January for the prior year; de minimis exclusions for small goods sellers	Member state tax authority
United Kingdom	Same categories under the OECD model rules	Annual digital platform report to HMRC	HMRC
Australia	Seller identity and payment data	Sharing Economy Reporting Regime	ATO
Canada	Seller identity and payment data	Reporting rules for digital platform operators	CRA
India	Seller PAN and GSTIN	TDS on e-commerce participant payments under section 194-O of the Income-tax Act; TCS under GST for e-commerce operators	Income Tax Department; CBIC
Mexico	RFC	Platform withholding of income tax and VAT on sellers	SAT

Thresholds and rates in this table change often; verify the current figures with the named authority before configuring withholding or reporting.

Procedures

Building the Payout Pipeline

1. Balance model: per seller, per currency: available, pending (in the dispute or delivery window), held (risk or compliance), and negative (refunds and chargebacks exceeding balance). Payouts draw only from available.
2. Schedule: per seller settings within your risk tier rules: daily, weekly, threshold-based, manual. Add a minimum payout amount that exceeds the rail's fee.
3. Batch creation: at cut-off minus a margin, select eligible balances, apply holds and minimums, apply withholding, and create payout records in state initiated with a unique payout reference that will travel on the rail (EndToEndId, ACH addenda, SWIFT remittance, Pix txid).
4. Instruction generation: group by rail and currency; generate the file (pain.001 for SEPA and many banks, Nacha for ACH, provider API for others); validate identifiers (IBAN check digits, CLABE check digit, routing number checksum, VPA format).
5. Funding: confirm the funding account holds the batch total in that currency before release; if converting, book the FX at the rate applied and store the rate record.
6. Release through the bank channel or provider API with an idempotency key per payout; store the provider's reference.
7. Status ingestion: accepted, settled, returned, with reason codes, via provider webhooks and bank reports (pain.002, camt.053/054, ACH return files); transition payout records and post ledger entries.
8. Statement: per payout, per seller: gross, fees, withholding, FX rate and markup, net, rail, reference, expected arrival.

Failure Handling

1. Validation failure before release: fix data with the seller; do not silently retry.
2. Reject or return after release: read the code and map to an action: account closed or invalid (SEPA AC01, AC04; ACH R02, R03, R04) means block further payouts and request new details; frozen or blocked (AC06, R16) means compliance review; name mismatch (VoP, CoP, DICT lookup mismatch) means verify with the seller before any retry; bank-side timeouts mean retry with the same idempotency key.
3. Short receipt (SWIFT deductions): treat as a fee to the seller only if disclosed and agreed; otherwise top up and change the charge option or rail.
4. Returned funds: post back to the seller's available balance with a returned event; never leave returned money in suspense across a period end.
5. Negative balances: net against future earnings automatically; after a defined period, invoice or debit under mandate with notice; escalate persistent negatives to collections.
6. Seller communication: every failure generates a message with the reason in plain language and the action needed; every retry is visible in the seller's payout history.
7. Run monitoring: batch acceptance rate, return rate by rail and reason, time to settlement by rail, sellers with two or more consecutive failures.

Worked Examples

Payout Ledger Sequence

Sale settled (seller share EUR 80.00):        Dr Platform receivable / Cr Seller payable (pending) 80.00
Delivery window passed:                       Dr Seller payable (pending) / Cr Seller payable (available) 80.00
Payout initiated (fee EUR 0.50):              Dr Seller payable (available) 80.00 / Cr Payout clearing 79.50, Cr Payout fee income 0.50
Bank debit confirmed (camt.053):              Dr Payout clearing 79.50 / Cr Cash at bank 79.50
Return received (AC04):                       Dr Cash at bank 79.50 / Cr Payout clearing 79.50
                                              Dr Payout clearing 79.50 / Cr Seller payable (available) 79.50

SEPA Payout Instruction (pain.001 fragment)

<CdtTrfTxInf>
  <PmtId><EndToEndId>PO-2026-09-02-000778</EndToEndId></PmtId>
  <Amt><InstdAmt Ccy="EUR">79.50</InstdAmt></Amt>
  <Cdtr><Nm>Example Seller B.V.</Nm></Cdtr>
  <CdtrAcct><Id><IBAN>NL91ABNA0417164300</IBAN></Id></CdtrAcct>
  <RmtInf><Ustrd>Payout week 36 2026, statement PO-2026-09-02-000778</Ustrd></RmtInf>
</CdtTrfTxInf>

The IBAN shown is a widely published example, not a real account. EndToEndId returns to you on the camt.053 entry and on any return, which is what makes the return postable without a human.

Identifier Validation

def iban_valid(iban: str) -> bool:
    s = iban.replace(" ", "").upper()
    if not (15 <= len(s) <= 34) or not s[:2].isalpha():
        return False
    rearranged = s[4:] + s[:4]
    numeric = "".join(str(int(c, 36)) for c in rearranged)
    return int(numeric) % 97 == 1

def clabe_valid(clabe: str) -> bool:               # Mexico, 18 digits, weights 3-7-1
    if len(clabe) != 18 or not clabe.isdigit():
        return False
    weights = [3, 7, 1] * 6
    total = sum((int(d) * w) % 10 for d, w in zip(clabe[:17], weights[:17]))
    return (10 - total % 10) % 10 == int(clabe[17])

Cut-off Table (illustrative structure)

rails:
  sepa_sct:     { cutoff_local: "15:00", tz: "Europe/Amsterdam", holidays: "TARGET2", value: "D+1" }
  sepa_inst:    { cutoff_local: null, holidays: null, value: "immediate" }
  ach_sameday:  { cutoff_local: "13:00", tz: "America/New_York", holidays: "FederalReserve", value: "D" }
  imps:         { cutoff_local: null, holidays: null, value: "immediate", note: "funding partner cut-off applies" }
  pix:          { cutoff_local: null, holidays: null, value: "immediate" }
  zengin:       { cutoff_local: "15:00", tz: "Asia/Tokyo", holidays: "JP", value: "D or D+1 by bank" }
  swift:        { cutoff_local: "14:00", tz: "Europe/London", holidays: "GB+USD", value: "D+1 to D+5" }

Confirm every cut-off with your bank or provider; they differ by bank and change.

Checklist

• KYC/KYB, UBO, sanctions and PEP screening completed and rescreened on a schedule; hits block and escalate.
• Beneficiary account verified by name match or deposit before first payout; identifiers checksum-validated.
• Tax form collected and validated; withholding rules loaded with effective dates; reporting data captured per payout.
• Balance model with pending, available, held and negative states; payouts draw from available only.
• Unique payout reference on every instruction; provider reference stored; idempotent release.
• Status ingestion from webhooks and bank files; return codes mapped to actions; returned funds re-credited automatically.
• Seller statement per payout showing gross, fees, withholding, FX rate and net.
• Funding checks per currency before release; FX booked at applied rate.
• Monitoring on acceptance, return and settlement-time by rail; alerts on consecutive failures.
• Licensing position for holding and transmitting seller funds confirmed with counsel in each market.

Common Mistakes

• Paying USD by SWIFT to an Indian or Brazilian seller who has a local rail, then absorbing complaints about short receipts.
• Skipping name verification and paying a fraudster who changed a seller's bank details through a compromised account.
• Generating bank files from a spreadsheet instead of from ledger state, so a rerun pays twice.
• Leaving returned funds in a bank suspense account across month-end.
• Withholding tax without collecting the form that would have reduced it, or not withholding when you must.
• Ignoring holiday calendars and promising Friday arrival for a Monday value date.
• Treating the payout provider's balance as the source of truth instead of your ledger.
• Releasing a batch without checking the funding account per currency.

Limits and When Not to Use This

This skill describes payout engineering and operations; it is not legal, tax or compliance advice. Whether your platform needs a payments or money-transmission licence to hold and disburse seller funds, what customer due diligence is required, and how sanctions obligations apply are questions for a regulatory lawyer and your compliance officer; verify with the relevant regulator (national competent authorities under PSD2, the FCA, MAS, RBI, Banco Central do Brasil, FinCEN and state regulators in the US). Withholding, information reporting and the current thresholds must be confirmed with the tax authority named above and a tax adviser. This skill provides no guidance on paying sanctioned or prohibited parties, structuring payments to avoid reporting, or circumventing capital controls.