"Is halfin compliant?" is the wrong question
iGaming is a regulated activity, and the regulation belongs to the operator. A casino, sportsbook, or poker room holds — or does not hold — a licence in each jurisdiction it serves, runs player onboarding, age and jurisdiction checks, responsible-gaming controls, and answers to a regulator. None of that transfers to a payment processor by plugging one in. halfin does not issue gambling licences, does not certify that your operation may run anywhere, and does not give legal or licensing advice. If a page, a salesperson, or a competitor tells you a crypto processor makes your gaming business "compliant", read that as a warning sign, not a feature.
So the useful question is not "is the processor compliant" but "where does each compliance responsibility live, and what does the payment layer actually do." That division is the whole point of this page. Get it right and the integration is clean: your platform owns identity and the decision to accept money or release a withdrawal; halfin owns the rail, the payment record, and signed status your compliance and finance teams can reconcile against. Get it wrong — assume the processor is doing KYC, or that an AML-aware rail excuses you from monitoring — and you have a gap that no amount of crypto cleverness closes.
The honest framing also protects you commercially. "Regulated" and "licensed" are words about a status, and halfin holds neither status on your behalf. Treating payment infrastructure as if it carried a licence is exactly the kind of claim that gets an operator in trouble with its own regulator. halfin processes payments; you carry the licence, or you carry the risk of operating without one. That line does not move.
KYB onboarding: halfin knows the business it processes for
Before a single deposit lands, halfin onboards the merchant through know-your-business (KYB) checks. KYB is about the entity, not the end player: who the operating company is, who stands behind it, and what it does. For a gaming operator this is the front door — halfin is processing payments for a real business it has identified, not an anonymous endpoint pointing money somewhere. That is a precondition for everything downstream, including being able to attach a payment trail to an accountable counterparty.
KYB is distinct from player KYC, and conflating the two is the most common mistake operators make when they assume "the processor handles compliance." KYB identifies the operator to halfin. Player KYC — verifying the individual depositing or withdrawing — stays entirely in your platform, because you are the one with the player relationship, the age and jurisdiction obligations, and the responsible-gaming duty. halfin never sees, and does not want to own, your player identity system. It processes the instruction your back office approves and returns a record you can tie back to your own player ID.
The practical upshot: KYB is a one-time-and-ongoing relationship between you and halfin; player KYC is a per-player relationship between you and the player. They do not substitute for each other, and a payment that clears the rail says nothing about whether your KYC was done. Your controls have to assert that themselves before you approve a deposit or release a cashout.
AML awareness and sanctions screening as process, not a certificate
Processing on halfin's rails is AML-aware. "Aware" is the precise word, and it is not hedging: it means anti-money-laundering considerations are built into how the rail behaves and how records are kept, not that halfin issues you an AML certification or absorbs your monitoring obligation. There is no certificate to wave at a regulator that says a payment processor made your gambling operation AML-clean. AML is an ongoing discipline your platform runs — transaction monitoring, thresholds, suspicious-activity escalation — and the payment layer's job is to give that discipline clean, signed, attributable data to work from.
Sanctions screening follows the same shape. It is a process you operate against your players and counterparties continuously, not a one-time gate the processor closes for you. On-chain, the payment record is durable and tied to the addresses involved, which is exactly the kind of artifact a screening and monitoring program needs as input. But the decision — does this player, this jurisdiction, this address belong in your flow — is yours, made against your own lists and your own risk appetite. halfin does not run your sanctions program; it gives you records the program can reason about.
The travel rule is worth naming explicitly because it gets cited as if it were a halfin-held status. It is not. Treat the travel rule as an educational concept and an operational expectation to design for as your program and jurisdictions require — a process, never a certification halfin carries for you. The pattern across all three is identical: AML, sanctions, and travel-rule expectations are disciplines you run; halfin's contribution is identified onboarding plus an auditable, signed payment trail you can plug into them.
- AML-aware processing — considerations built into the rail and records, not an AML certification halfin issues.
- Sanctions screening — a continuous process you run against your own lists; halfin provides attributable payment records as input.
- Travel rule — an educational concept and operational expectation to design for, never a halfin-held status.
- Suspicious-activity monitoring and escalation stay in your platform; the payment trail feeds it.
Who owns what
The cleanest way to plan an integration is to put each compliance responsibility in one column and not let it drift. The table below is the division halfin works to: anything touching player identity, eligibility, and the decision to move money is the operator's; anything touching the rail, the record, and onboarding the operator itself is halfin's. Use it as a checklist when you scope your controls — every row that lands in your column needs a control in your platform, not an assumption that the rail covers it.
| Responsibility | Operator (your platform) | halfin (payment layer) |
|---|---|---|
| Gaming licence / jurisdiction approval | Owns it — with its own counsel and regulator | None — infrastructure, not a licence |
| Player identity (KYC) | Owns it — system of record for player identity | Never sees player KYC; processes the approved instruction |
| Age / jurisdiction eligibility checks | Owns it before accepting a deposit | None |
| Responsible-gaming controls | Owns it — limits, exclusions, interventions | None |
| AML monitoring & SAR escalation | Owns it — ongoing program | AML-aware processing; provides signed records as input |
| Sanctions screening | Owns it — continuous, against own lists | Provides attributable, address-level payment records |
| Merchant (operator) identity | Provides KYB information | Owns KYB onboarding of the operator |
| Payment execution & settlement | Approves the instruction | Executes the rail, reorg-aware, per-chain confirmations |
| Payment record & audit trail | Reconciles against own ledger | Produces signed events and dashboard records |
How signed records support your controls
Compliance programs run on data, and the data has to be trustworthy. halfin's payment surface is built so that the record driving your ledger is the signed one, not the cosmetic one. When an invoice is paid or a payout completes, your server receives an HMAC-signed webhook; you verify the signature before taking any business action, and only then move a player balance or mark a withdrawal settled. A checkout redirect or a dashboard glance is for humans — the signed event is what your automated controls and your auditors should trust.
That discipline is what makes a payment record useful for AML and screening. Because every credit and payout is tied to identifiable addresses and confirmed under the chain's own rules — reorg-aware, at per-chain confirmation thresholds — the artifact you feed into monitoring is final and attributable, not a hopeful UI state. When you attach each invoice and payout to your own player ID, you can answer "which player, which address, how much, confirmed when" from your own records, which is exactly the question a monitoring or screening review asks.
The canonical events are deliberately small and named: invoice.confirming, invoice.paid, invoice.underpaid, invoice.overpaid, invoice.expired, and payout.completed. Underpaid and overpaid matter for compliance specifically — a mismatch against the quoted amount is recorded explicitly rather than disappearing into a silent discrepancy your review discovers months later. Verify the signature, log the event against your player, and your audit trail writes itself. The full webhook envelope and schema live at docs.thehalfin.com.
Approving a withdrawal: your decision, halfin's execution
The split is easiest to see on a withdrawal, where the compliance decision and the payment execution are obviously two different acts. Your back office decides whether a cashout may go out — KYC status confirmed, wagering met, fraud and sanctions screening cleared. That decision is yours and nothing on the rail overrides it. Once you approve, you create a payout to the player's wallet; each line carries a currency, an amount as a string, a destination, and an idempotency_key so a retried request never double-pays. halfin executes it on the same chains you accept deposits on, and the payout.completed webhook is what moves the player balance and your treasury record.
The idempotency key is also a compliance-grade property, not just an engineering convenience: a payout you approved exactly once executes exactly once, even through a timeout or a worker restart, so your audit trail shows one approval mapped to one settlement. The example below is the shape of a single approved cashout — the full request and response schema is at docs.thehalfin.com.
# Your platform has already cleared KYC, wagering, and screening for this
# cashout. Only then do you create the payout. The idempotency_key ties
# one approval to exactly one on-chain settlement.
curl -X POST https://api.thehalfin.com/api/v1/payouts \
-H "X-API-Key: $HALFIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"currency": "USDT",
"amount": "120.00",
"destination": "TXk...playerWalletOnTron",
"idempotency_key": "cashout-player-8821-00417"
}'
# Verify the signature on the payout.completed webhook before you mark
# the withdrawal settled in your ledger. See docs.thehalfin.com for the
# full payout and webhook schemas.