What 'compliance' means for an education business taking crypto
Education compliance is usually discussed as one undifferentiated obligation, but on a payment flow it decomposes into a handful of specific, answerable questions. Who is the legal entity collecting tuition and authorizing payouts, and was it verified? Are the payments moving through the account screened, and is there a record of that? Can the school tie a confirmed tuition payment back to a specific student and cohort, and a contractor payout back to a specific payee and period? And can it show the same student was not double-charged and the same instructor not double-paid? Those are the questions a bank partner, an audit, or a payment-rail provider asks, and a defensible process answers each with evidence rather than recollection.
halfin sits on the payment side of those questions. It does not decide which students are eligible, whether a program is accredited, or what a given course is allowed to teach in a given country — those judgments live in the school's enrollment, admissions, and academic 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 invoice and every payout. The posture is a partnership: the school supplies the academic and eligibility decisions, halfin supplies the payment execution and the evidence.
One point worth stating plainly: halfin is infrastructure, not a license and not an accreditation. A school may be licensed, registered, or accredited in its own jurisdiction, and that status belongs entirely to the school — halfin does not hold, grant, or stand in for it. Treat the items below as process to understand and run with your own counsel, not a compliance certification you inherit by integrating. Nothing here is legal advice.
KYB at onboarding, before any money flows
Compliance starts before the first tuition payment lands. When an education business becomes a halfin merchant it goes through KYB onboarding — know-your-business verification of the legal entity that will collect 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-student checks the school runs on its own side at enrollment.
Keep the two layers distinct, because conflating them is where schools get into trouble. KYB verifies the merchant — your school, bootcamp, or course business as a legal entity. It does not verify your students, and halfin makes no claim about them. Student identity, the decision about who is eligible for a program, and any age, residency, or prerequisite checks remain the school's responsibility and stay in the school's systems. halfin receives the invoice you create and the payout instruction you approve; it does not assess whether the student behind a payment should be enrolled.
KYB is also not the school's accreditation. A bootcamp passing KYB has verified itself as a business that can receive funds — it has not acquired any educational credential, and it cannot present KYB as one. The two live in separate domains and should never be presented as the same thing to a regulator or a student.
- KYB at onboarding establishes the education business as a merchant — a one-time, account-level gate.
- Student identity, eligibility, and program prerequisites stay in the school's enrollment and admissions systems.
- KYB verifies the business; it is not the school's accreditation and cannot be presented as one.
- halfin executes the invoice and the approved payout; it does not adjudicate who should be enrolled.
AML awareness on tuition in and payouts out
AML awareness is a process the rail applies to the movement of funds, not a certificate the school can hang on the wall. On the inbound side, tuition arrives as a confirmed on-chain payment against an invoice; the counterparty and the deposit are screened as part of how halfin processes payments, and the result is recorded against the invoice rather than discarded. On the outbound side, payouts to instructors and contractors are screened as a movement of funds before they are released. None of this replaces the screening the school owns on its own side — it complements it.
The control point that matters for the school is the pending-approval step on payouts. 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 back office submitting the batch) and the release path (a human or a policy approving it) are separate by design. Run your own counterparty and wallet screening between those two steps: stage the contractor or scholarship batch, screen the destinations against your sanctions and watchlist sources, and release only 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 halfin handles on its own: a destination is checked for the chosen network before a 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 the school paying into a broken address; the school's own screening stops it paying a counterparty it should not pay.
Cross-border education adds questions halfin does not answer
An online school selling the same course into a hundred countries inherits a different obligation in each one, and almost none of those obligations are about payment. Whether a program may be marketed or delivered in a given country, whether a credential is recognized there, whether a minor may enroll, what consumer-protection and cooling-off rules apply, what tax treatment tuition carries — these are jurisdiction-specific education and consumer-law questions, and they sit squarely on the school's side. A crypto payment rail does not make any of them go away, and it would be a mistake to read "halfin handles cross-border payments" as "halfin handles cross-border compliance."
What the rail does change is the evidence the school can produce. Because collection, payouts, conversion, and refunds all run through the same API and dashboard, the school has a single, consistent record of where money came from and where it went — independent of how many countries the students and instructors sit in. That is what makes a cross-border operation auditable: one place to show a banking partner the inflows and outflows, rather than a different statement and reconciliation method per region. The school still answers the legal questions; halfin keeps the financial trail behind them clean.
The travel rule is a useful example of a concept to understand as process, not status: it is an operating idea about how information accompanies certain transfers, relevant to how payments are recorded and screened, and never a certification halfin holds on a school's behalf.
Who owns what: the compliance boundary
The cleanest way to keep an education payment integration maintainable is to draw the boundary explicitly and keep each side's system of record on its own side. The school owns who the student is, whether they qualify for the program, and the legal obligations of teaching where it teaches. halfin owns whether a payment confirmed, where it came from, where a payout went, and the records of all of it. The two reconcile through signed events, and neither tries to do the other's job.
The table below is the boundary in concrete terms — the same split a finance team should be able to recite when a banking partner or an auditor asks who is responsible for what. When in doubt, the rule of thumb is simple: academic and eligibility decisions belong to the school; the execution and the record of money moving belong to the rail.
| Responsibility | Owned by the school | Owned by halfin (the rail) |
|---|---|---|
| Student identity and eligibility | Yes — admissions, KYC, age/residency checks | No |
| Program accreditation and approvals | Yes — institutional, in its jurisdiction | No |
| Merchant entity verification (KYB) | Provides documents | Performs KYB at onboarding |
| Counterparty / wallet screening | Owns the decision and the watchlists | AML awareness on the rail; address validation |
| Tuition collection record | Reconciles against its catalog price | Invoice + confirmation + signed webhook |
| Instructor / contractor payout record | Approves the batch | Payout + idempotency key + transaction hash |
| Cross-border education and tax law | Yes — with its own counsel | No |
The audit trail an integration leaves behind
The practical payoff of the boundary above is that every payment leaves an artifact the school can point to. A tuition payment resolves to an invoice, a confirmation under the chain's threshold with reorg-aware crediting, and an HMAC-signed webhook your backend verified before acting. An instructor or scholarship payout resolves to an idempotency key, a dashboard approval record, and an on-chain transaction hash. None of that is recollection — it is data finance can export and show.
Idempotency is the load-bearing property on the payout side. Each payout line carries its own idempotency_key, so a contractor batch retried after a network timeout settles once, not twice — which is both an operational safeguard and a compliance point, because "we never double-paid a publisher or an instructor" is an answerable question rather than a hopeful one. The minimal shape of an approved-batch line below shows where that key lives; the full request and response schemas are defined at docs.thehalfin.com.
Pair that with the signed webhook on the inbound side and the school has both halves of the trail. Verify the HMAC signature on every event before acting on it, then attach the confirmed invoice or completed payout to the student, cohort, or contractor in your own records. That attachment is what turns a pile of on-chain transactions into a reconciliation a finance team and an auditor can both follow.
# One line of an approved payout batch — fan-out over POST /api/v1/payouts,
# one idempotency_key per line so a retried run settles once, not twice.
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": "800.00",
"destination": "TXk9z...instructorWallet",
"idempotency_key": "00000000-0000-4000-8000-000000000042"
}'
# Submitting enters pending-approval; release happens in the dashboard after
# the school screens the destination. The completed payout resolves to a
# transaction hash and a payout.completed webhook — verify its HMAC first.
# Full schemas: docs.thehalfin.com.