Compliance is a process, not a badge you bolt on
The instinct on a payments project is to hunt for a badge — a license number, a certificate, a single line that says "compliant" — and treat it as a gate you pass once. Crypto payments do not work that way, and pretending otherwise is how teams end up with a defensible-looking integration and no defensible record behind it. What exists instead is a process shared between you and your provider: your business is verified before it transacts, money movement through your account is watched for the patterns that matter, certain obligations that come with moving value are understood, and every outbound action leaves a trail someone can review later.
Framing it as a process also clarifies who owns what. halfin operates the controls that sit inside the product — onboarding verification, scoped permissions on who can move funds, operator approval on payouts, an audit trail on outbound money, reorg-aware crediting that reflects funds which actually settled. It does not make regulatory promises beyond that boundary, and it never describes itself as licensed or regulated as a status. The parts specific to your business — whether your activity is permitted where you operate, what you must report, how you treat your own customers — stay with you. Read this guide as a map of that split, not as a compliance opinion about your specific case.
- KYB onboarding — your business is verified before it can transact, not after.
- AML awareness — money movement is watched for patterns that warrant attention; ongoing, not a one-time gate.
- Sanctions and PEP screening — checked at onboarding and revisited as lists and profiles change.
- Travel rule — an obligation you may carry when value moves between providers; a concept here, not a certification.
- Audit trail — every outbound movement is attributable: who drafted it, who approved it, when.
- Not legal advice — what is lawful for your business in your jurisdiction is a question for your counsel.
Step 1 — KYB onboarding: get verified before you build
KYB — know your business — is the verification of your company before it can move money, the business-side counterpart to the KYC checks consumers go through. It happens at onboarding, deliberately, so that an account is verified before any funds flow through it rather than after a problem surfaces. Expect to provide information about the business, its ownership and control, its authorized representatives, and the nature of its activity, along with supporting documentation. The depth of what is asked scales with the risk the activity presents; the principle is constant — the platform knows who it is providing infrastructure to before that infrastructure is switched on.
Treat onboarding as the place where scope is settled, not as paperwork to rush. Some activities and some regions are out of scope, and that is determined here, in a conversation where the specifics of what you do can actually be assessed, rather than discovered silently at runtime when a payout is blocked. If you have any doubt about whether your business is in scope — a borderline vertical, customers in regions you are unsure about — raise it now. Being onboarded is not a certification that your business is lawful in any jurisdiction; it is the start of a verified relationship, and the right time to surface anything that could become a problem later.
- KYB happens at onboarding — before money moves, not after.
- You verify the business, its ownership, its representatives, and the nature of its activity.
- Depth scales with risk; the principle (verify before switch-on) does not.
- Scope — which activities and regions are in or out — is settled here, in conversation.
- Onboarding is not a certification that your business is lawful anywhere; it is a verified starting point.
Step 2 — AML awareness: an ongoing posture, not a gate
Anti-money-laundering work is easy to picture as a one-time check at the door. In practice it is a posture you hold continuously. AML awareness means money movement through your account is considered in the context of what is known about your business — its stated profile, its expected behavior — so that activity which is unusual, inconsistent, or otherwise indicative of elevated risk can surface and be looked at. It is risk-sensitive: a profile that changes can be reassessed, and activity that drifts from what you described at onboarding is exactly what monitoring is meant to catch.
Where something warrants attention, the operational response is the ordinary toolkit — a request for more information, an explanation of particular activity, a temporary restriction, or escalation for internal review — and cooperating with reasonable requests of that kind is part of the relationship. None of this is a substitute for your own obligations. If your business independently carries monitoring or reporting duties toward your own end customers or an authority, those remain yours; the platform's AML awareness covers the infrastructure layer, not your downstream relationships. The split is worth stating plainly to your own team so nobody assumes the provider is carrying a duty that actually sits with you.
Step 3 — Sanctions and PEP screening
Screening sits alongside KYB and AML rather than replacing either. The intent is to check merchants — and, where it is relevant to risk, the individuals associated with them — against applicable sanctions lists and watchlists, and to consider exposure to politically-exposed persons (PEPs). Screening is not a single moment: it happens at onboarding and may be repeated on an ongoing basis, because lists change and a merchant's profile evolves. A clean check today is not a permanent clearance.
A match, or a close-enough potential match, does not automatically mean a door slams — it typically means additional review, a request for more information, restrictions, or, where appropriate, a decision not to proceed. The point of describing this up front is so it is not a surprise: a payments relationship that touches sanctioned persons, entities, or jurisdictions, or that looks structured to evade sanctions controls, is out of scope by design. None of this is a status halfin holds or confers; it is process. The specific lists and providers used are operational details, and any indicative description of restricted regions lives in the restricted-countries draft, which is indicative only, not a binding list.
Step 4 — The travel rule, in plain terms
The travel rule is the obligation, in many jurisdictions, to pass certain originator and beneficiary information alongside transfers of value above a threshold when they move between regulated providers — so that money crossing services carries identifying context with it instead of moving anonymously end to end. It exists precisely because anonymous value transmission is where illicit flows hide. It is worth understanding early because it can shape how some flows are structured, even though most merchants will not implement it directly.
Two things are true at once, and both matter. First, this is an educational explanation, not a description of a certification halfin holds: halfin can support the operational side of such obligations where they are relevant — for example, by being able to collect and convey the information they call for — and it never presents the travel rule as a license or a compliance status. Second, whether the travel rule applies to a specific transfer, at what threshold, and exactly what you must record turns on your jurisdiction and your role in the transaction. That determination is a legal and onboarding question. Treat the rule as context for designing flows, and confirm its application to your situation with someone qualified to say.
Step 5 — Build an attributable record of money movement
The single most useful thing an integration can produce for compliance is a record a reviewer can trust. Crypto payments are irreversible, which raises the stakes on every outbound transfer — there is no chargeback to undo a mistake — so the controls around moving money are also the controls that produce your audit trail. Payouts are drafted and then separately approved by an operator before anything is signed or broadcast, and that authorization is recorded: who drafted it, who approved it, and when. A leaked or over-broad credential should never be able to initiate a payout on its own, which is why the money-moving service holds a payouts-scoped API key, separate from the read-only key reporting uses and the invoicing key your storefront uses.
On the inbound side, crediting is reorg-aware and waits for each chain's confirmation threshold, so a balance reflects funds that actually settled rather than a transaction that might still unwind. That distinction matters to a reviewer: "credited" means settled to the depth the chain requires, not optimistically first-seen. Refunds inherit the same discipline — because an on-chain payment cannot be un-sent, a refund is a fresh outbound transfer that runs through the same drafted-approved-recorded path and leaves a trail tying it back to the original payment. Handling disputes and goodwill through that deliberate flow, rather than ad-hoc transfers from a hot wallet, is what keeps your money movement traceable when finance or an AML reviewer asks.
Drive your own reconciliation from signed events, not from guesswork. balance.credited and payout.completed tell you when money has actually settled in or out; verify the HMAC signature over the raw request bytes with a constant-time compare before you act on any of them, because an unverified payload is not a basis for a ledger entry. A reconciliation built on verified events gives you a per-transaction record whose status means "settled," which is exactly the kind of attributable history a compliance review depends on.
- Payouts are drafted, then operator-approved before signing — the approval is recorded and attributable.
- Use scoped API keys: a payouts key for money-out, separate from read-only and invoicing keys.
- Reorg-aware, threshold-respecting crediting means "credited" equals settled, not first-seen.
- Refunds run through the same approved, recorded outbound path — never ad-hoc transfers.
- Reconcile from HMAC-verified webhooks (balance.credited, payout.completed), not by polling or guessing.
Step 6 — Keep the record, and keep the line clear
Once the operational controls are producing an attributable trail, the remaining discipline is to retain it and to be honest about where the provider's responsibility ends. Records relating to onboarding, verification, screening, and money movement are worth keeping for an appropriate period — both because a reviewer may ask for them and because your own obligations may require it. Store webhook events durably before you acknowledge them, log the event id and the verification result for every delivery, and keep the payout authorization history intact. The goal is that when someone asks "what happened with this transaction," the answer is a record, not a reconstruction.
Then hold the line on what compliance copy can and cannot say. halfin operates the plumbing and keeps the receipts; it does not absorb your legal responsibilities or describe itself as licensed or regulated. Whether a particular flow is lawful for your business, what you must report, and which registrations you must hold are questions for your own qualified counsel and, where scope is concerned, for the onboarding conversation. Nothing in this guide is legal advice. Use it to understand how compliance works as a process and where the boundary sits — then get the specifics confirmed by someone qualified to confirm them.
A worked example: the attributable payout
To make "attributable record" concrete, here is the shape of a single outbound payment that produces one. The request itself is ordinary — currency, amount, destination, and an idempotency_key in the body — but two properties make it compliance-friendly. The idempotency_key is deterministic and derived from your own records, so a retry after a timeout never produces a second payment and your ledger and the platform agree on exactly what was sent. And the call only stages the payout: it enters a pending-approval state and is released by an operator from the dashboard, so the act of moving money is separated from the act of requesting it, and both are recorded.
That separation is the audit trail. The request below is what your service sends; the approval that follows is a distinct, attributable action. Reconcile the result from the signed payout.completed webhook rather than assuming the broadcast equals settlement. The full request and response schema lives at docs.thehalfin.com; what matters for compliance is the pattern — deterministic key, staged then approved, reconciled from a verified event.
# Stage one outbound payout. The idempotency_key is a snake_case BODY field,
# derived from your own records so a retry never double-pays. The payout enters
# pending-approval and is released by an operator from the dashboard — the
# request and the approval are two separate, recorded actions.
curl -sS -X POST https://api.thehalfin.com/api/v1/payouts \
-H "Content-Type: application/json" \
-H "X-API-Key: $HALFIN_PAYOUTS_API_KEY" \
-d '{
"currency": "USDT_TRC20",
"amount": "250.00",
"destination": "TXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"idempotency_key": "refund:ord_4821:2026-06"
}'
# Reconcile from the signed payout.completed webhook — verify the HMAC over the
# raw bytes before recording anything. See docs.thehalfin.com for the full schema.