The travel rule is not a switch you flip or a certificate you frame on a wall. It's information that has to ride alongside the money — and whether it has to ride alongside your money is a question only your jurisdiction and your counsel can answer.
We get asked about the travel rule the way people ask about the weather before a flight: with a vague dread that it's about to ruin the trip. It usually isn't. But the merchants who get blindsided are the ones who treated it as either a non-issue or a feature they could buy. It's neither. This is the plain-English version we wish more people heard before they built their flows, not after.
This is informational, not legal advice. Whether the rule applies to you, at what threshold, and what you must record are legal and jurisdictional questions for someone qualified to answer them about your specific business. We'll be precise about where our explanation stops.
What the rule actually says
The name is the whole idea: certain identifying information has to travel alongside a transfer of value, instead of dropping off at the boundary between two services.
When a regulated provider sends a transfer above a defined threshold to another regulated provider, the sending side is required to collect and forward a set of details about the originator (the party sending) and the beneficiary (the party receiving). So the receiving provider learns who is on the other end, rather than seeing only an address and an amount.
That's it. It's a recordkeeping-and-forwarding duty layered on top of the transfer. The transfer itself still happens the same way; the rule is about the context that accompanies it.
Three conditions decide whether it bites, and you have to read them together:
- Between regulated providers. The obligation attaches to the providers transmitting value — not to an individual moving their own funds between their own wallets.
- Above a threshold. There's a monetary floor, set by the jurisdiction, below which the requirement doesn't apply.
- Per jurisdiction and per role. What counts as a regulated provider, what threshold applies, which fields you record, and how you transmit them all vary by where you operate and by whether you're the sending or receiving side. There is no single global version of the rule.
If you've read our travel rule glossary entry, this is the same boundary drawn the same way — because it's the boundary that matters, and we'd rather repeat it than let anyone walk away thinking it's optional fine print.
Why it exists at all
The travel rule didn't start with crypto. It comes from anti-money-laundering frameworks for traditional wire transfers, where the same logic has applied for decades: a bank sending a wire has to send identifying information with it, so the receiving bank isn't accepting value from a complete blank.
The reasoning is mechanical, not moral. A transfer that is anonymous end to end is exactly the kind of gap illicit flows exploit — money that arrives somewhere with no recorded sender, no recorded recipient, and no way to reconstruct who moved it. Requiring the information to travel closes that gap at the point where two regulated parties hand value across to each other.
When regulators extended AML frameworks to providers that transmit crypto value, they extended this rule along with them. The underlying concern is identical: don't let the regulated boundary between two services become a place where the audit trail vanishes.
The travel rule is boring on purpose. It's an audit-trail rule, not a surveillance feature. The goal is that a qualifying transfer between two regulated parties leaves a record of who sent and who received — nothing more exotic than that.
What it is not — and this is the part people get wrong
Because the rule has a name and a reputation, it gets mistaken for things it isn't. Three corrections that save real pain:
- It is not a certification or licence a provider holds. No payment provider — halfin included — "has" the travel rule the way a building has a fire certificate. It's a recurring obligation that may apply to certain regulated providers on each qualifying transfer, not a status you acquire once and display. If a vendor tells you they're "travel-rule certified," treat that as a vocabulary problem at best.
- It is not a setting in an API. You will not find a
travel_rule: truefield in our API, because there's nothing honest to put behind one. The rule turns on facts about your business and your jurisdiction, not on a boolean a payment surface can toggle. - It is not a one-time box-tick that makes you "compliant." It's one recurring requirement inside a broader compliance posture. Satisfying it on one transfer doesn't end your obligations on the next, and it doesn't substitute for the rest of your AML responsibilities.
We're blunt about this for the same reason we're blunt in the high-risk merchant playbook: the merchants who struggle with crypto are usually the ones who were sold the idea that it makes compliance disappear. It doesn't. A serious payment partner won't pretend otherwise, and you shouldn't want one that does.
Where halfin stands — and where it stops
halfin is digital-asset payment infrastructure. We treat the travel rule the way we treat compliance generally: as a process we support operationally, never as a certification or licence we hold. We don't describe ourselves as licensed or regulated as a status, and you won't see us do it here.
What we actually provide is the operational foundation an obligation like this sits on top of, and it's concrete:
- Businesses are verified at onboarding — KYB, Know Your Business — before any money moves.
- The actions that move funds run through scoped API keys and operator approval. A payout enters a pending-approval state and is released from the dashboard before funds move, so outbound movement is a deliberate, attributable action — not an unsupervised one.
- That movement is recorded, so it can be reviewed. An audit trail is the raw material any recordkeeping obligation runs on.
That's the support. Here's the boundary, stated plainly: whether the travel rule applies to your transfers, what you must capture, at what threshold, and how you must forward it, are yours to determine with your counsel. The questions that decide it — your jurisdiction, your activity, your role in each transfer — are exactly the kind that get assessed in the onboarding conversation, where the specifics of your business can actually be evaluated, rather than answered by a marketing page.
Our compliance FAQ covers how KYB onboarding and the ongoing AML posture work in practice, and the AML policy lays out the platform's stance in full. Read both before you assume crypto acceptance is the unregulated option — because it isn't, and building as though it were is how a payment project discovers a requirement late, when changing the flow is expensive.
The practical takeaway
If you're building crypto acceptance, the honest move is to surface this question early, not to wave it away and not to panic over it.
Ask it during onboarding, in the same breath as everything else about your business: given where I operate, what I sell, and my role in each transfer, do obligations like the travel rule attach to me — and if so, how do I structure flows so the information I might need is captured at the right moment rather than reconstructed after the fact? That's a conversation between you, your counsel, and the people who onboard you. It is not a question a blog post or an API setting can close.
What we'll commit to is the part that's actually ours: keeping the operational plumbing clean, the permissions scoped, and the record accurate, so that whatever compliance obligations do apply to you have a solid foundation to stand on. Where your legal posture begins, our explanation ends — and anyone who blurs that line is selling you something they can't deliver.
P. Nair, halfin compliance