Compliance for affiliate payouts: KYB, screening, and an audit trail

When a regulator, a bank partner, or an internal audit asks an affiliate network to show how it pays its publishers, a spreadsheet of 'paid' checkboxes is not an answer. The questions are concrete: who are these counterparties, how did you decide to pay them, did you screen the wallets before money left, and can you tie each payment to a specific publisher and period? This page covers how halfin's payment rail supports that process — KYB when you onboard, AML awareness on the rail, and a payout that resolves to an idempotency key, a dashboard record, a signed webhook, and an on-chain transaction hash — and, just as importantly, where the boundary sits. The program owns publisher identity, the decision to pay, sanctions and wallet screening, and the regulatory obligations of its own jurisdiction. None of what follows is legal advice.

What 'compliance' actually means on a payout run

Affiliate compliance is usually discussed as a vague obligation, but on a payout run it decomposes into a few specific, answerable questions. Who is each recipient, and did the program verify them? Was the destination wallet screened against sanctions and known-bad lists before funds moved? Is there a record that survives staff turnover and a year of hindsight, tying each payment back to a publisher and a conversion period? And can the program demonstrate that the same publisher was never paid twice for the same earnings? Those are the questions an audit, a bank partner, or a payment-rail provider will ask, and a defensible process answers each one with evidence rather than recollection.

halfin sits on the payment side of those questions. It does not decide which publishers are legitimate, what they are owed, or whether a given counterparty is one the program is willing to pay — those judgments live in the network's tracker, anti-fraud, and partner-ops systems. What halfin provides is a rail that supports KYB at onboarding, applies AML awareness to the movement of funds, and leaves a concrete trail behind every payout. The compliance posture is a partnership: the program supplies the vetting and the decisions, halfin supplies the execution and the evidence.

The hard prohibition worth stating plainly: halfin is infrastructure, not a license. The program may be licensed or registered in its own jurisdiction, and that status belongs to the program. halfin does not hold, grant, or stand in for any such authorization, and nothing on this page is legal advice. Treat the items below as process to understand and run with your own counsel, not as a compliance certification you can inherit by integrating.

KYB at onboarding, before any money flows

Compliance starts before the first payout. When a business becomes a halfin merchant it goes through KYB onboarding — know-your-business verification of the legal entity that will receive deposits and authorize payouts. That establishes who the account holder is on the halfin side and is a prerequisite for moving real funds. It is deliberately a one-time, account-level gate, separate from the per-publisher checks the program runs on its own side every cycle.

Keep the two layers distinct, because conflating them is where programs get into trouble. KYB verifies the merchant — your network as a legal entity. It does not verify your publishers, and halfin makes no claim about them. Publisher identity, the decision about which counterparties you are willing to pay, and the vetting that sits behind that decision remain the program's responsibility and stay in the program's systems. halfin receives the approved payout instruction; it does not assess whether the publisher behind a given wallet should be paid.

• KYB at onboarding establishes the merchant entity on the halfin side — a one-time, account-level gate.
• Publisher KYC, vetting, and the decision to pay stay in the program's tracker and partner-ops systems.
• halfin executes the approved instruction; it does not adjudicate publisher legitimacy.
• The program's own licensing or registration is the program's status — halfin neither holds nor grants it.

Screen the wallet before the payout is approved

The screening that matters most for a payout happens before funds move, and it happens on the program's side. Before you approve a publisher for payment, screen the destination wallet and the counterparty against your sanctions and watchlist sources — that is a control the program owns, run against the program's data, with the program's risk appetite. halfin does not replace that decision; the value of the rail is that it gives you a clean control point to attach it to.

That control point is the pending-approval step. A payout you submit through the API does not move funds the instant it is called — it enters a pending-approval state and is released from the dashboard. So the staging path (your integration POSTing the batch) and the release path (a human or a policy approving it) are separate by design. Run your sanctions and wallet screening between those two steps: stage the batch from your tracker's approved-earnings export, screen the destinations, and only release the lines that clear. A line that fails screening is simply not released, and there is a dashboard record of that decision.

Address validation is a baseline that halfin handles on its own: a destination is checked for the chosen network before the payout is accepted, so a malformed address or a wallet that cannot receive the selected asset is rejected up front rather than burning a send. That is a correctness check, not a sanctions check — the two are complementary. Validation stops you paying into a broken address; your screening stops you paying a counterparty you should not pay.

The audit trail: one payout, four pieces of evidence

The reason the old CSV process fails an audit is that it leaves nothing trustworthy behind. A checkbox is not evidence, and a bank statement weeks later does not tie a line back to a specific publisher and conversion period. halfin's settlement leaves a concrete, multi-part trail for every payout, and the four pieces reinforce each other: an idempotency key derived from your ledger, a dashboard record of the approval, an HMAC-signed webhook your platform stores independently, and an on-chain transaction hash anyone can verify. When a publisher disputes a payment or finance closes the period, the chain of evidence is reconstructed from records, not from memory.

Each piece answers a different question. The idempotency key answers 'which earning period and publisher does this payment correspond to, and was it ever paid twice'. The dashboard record answers 'who approved it and when'. The signed webhook answers 'what did the program's own system independently record as the outcome' — and because it is HMAC-signed, your platform verifies the signature before treating it as truth, so a spoofed callback cannot poison the record. The transaction hash answers 'did this actually settle on-chain, and to what depth' — it is the part a support agent can hand to a publisher who asks where their money is.

No double-pay is a compliance property, not just an ops one

Paying the same publisher twice for the same earnings is not only a treasury loss — it is a finding. An auditor reading a payout log wants to see that the program cannot accidentally pay an earning period twice, and that the control is structural rather than dependent on someone reading a spreadsheet carefully. halfin makes that property structural through idempotency keys: every payout carries a caller-supplied key, and re-submitting the same key returns the original payout instead of creating a new one.

Derive the key deterministically from your ledger — typically the affiliate's account id joined with the payout period — so the same publisher in the same cycle always produces the same key. That determinism is what turns a fragile manual run into an auditable one: a timeout retry, a worker restart, or a re-run of the file converges on exactly one payout per recipient per period, and the log shows it. The example below stages a payout line through the API; note that the key, not the address, is what makes the operation safe to repeat.

# One affiliate payout line. The idempotency_key is derived from your ledger
# (account + period), so a retry returns the original payout — never a second one.
curl -sS -X POST https://api.thehalfin.com/api/v1/payouts \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $HALFIN_API_KEY" \
  -d '{
    "currency": "USDT",
    "amount": "420.00",
    "destination": "TXk9... (screened before this call)",
    "idempotency_key": "affiliate-9213-2026-06"
  }'
# The payout enters pending-approval; release it from the dashboard after
# wallet/sanctions screening clears. Schemas: docs.thehalfin.com.

Where the compliance boundary sits

The clearest way to keep an affiliate program out of trouble is to be explicit about which side owns what. The program owns the things that require judgment about people and jurisdictions: publisher identity and KYC, the decision about which counterparties it will pay, sanctions and wallet screening before funds move, the handling of high-risk niches, and the regulatory obligations of its own market. halfin owns the things that are mechanical and verifiable: KYB on the merchant entity, address validation, the pending-approval control point, idempotent execution, and the signed, hashed audit trail.

Travel-rule considerations and broader AML obligations sit in the gap, and the honest framing is that they are a process to understand, not a feature to switch on. halfin applies AML awareness to the payment rail and treats the travel rule as an educational concept — it is not a certification or license that halfin holds or that integrating confers. Where those obligations apply to your program, they are yours to meet with your own counsel and your own controls. Use the FAQ on compliance and the AML notes in the legal section as starting context, not as a substitute for legal advice. The takeaway is steady across every affiliate flow on this rail: keep vetting and the decision to pay inside your platform, hand halfin the approved instruction, and lean on the dashboard records, signed webhooks, and transaction hashes as your settlement evidence.

• Program owns: publisher identity, the decision to pay, sanctions/wallet screening, jurisdictional obligations.
• halfin owns: merchant KYB, address validation, the approval control point, idempotent execution, audit trail.
• Travel rule and AML are process to understand with your own counsel — never a certification halfin grants.
• Nothing here is legal advice; the legal pages are drafts pending review.