Every platform that embeds wallets eventually has the same meeting. Legal asks who is doing KYC. Engineering asks what the Travel Rule means for the API. Someone asks whether holding user wallets makes the company a custodian now. The meeting usually produces more questions than answers — so this article is structured as exactly that meeting, question by question.
01 — Who does KYC: you or your WaaS provider?
Both — but different parts, and getting the split wrong is the most common compliance mistake in embedded wallets.
The WaaS provider typically supplies the tooling: identity verification flows, document checks, sanctions and PEP screening, and on-chain KYT (know-your-transaction) monitoring exposed as API endpoints. That's infrastructure.
The platform owns the program: deciding which users get verified at which tier, setting risk thresholds, acting on alerts, filing reports where required, and keeping records. A provider can flag a suspicious transaction; only you can decide what your product does about it — and a regulator will address the question to you, not your vendor.
The practical test: if an obligation involves a decision about your users or your risk appetite, it's yours. If it's a capability that needs to exist in software, it's the provider's.
02 — When does the Travel Rule actually apply?
The FATF Travel Rule requires that identifying information about the sender and recipient travels along with a crypto transfer — but it doesn't apply to everything. Two conditions have to line up.
First, the transfer crosses the threshold — the FATF baseline is USD/EUR 1,000, though jurisdictions implement it differently, and some apply no minimum at all. Second, both ends of the transfer are VASPs — exchanges, custodial platforms, or other regulated intermediaries. When both are true, originator and beneficiary data must accompany the transfer.
When one end is a self-hosted wallet, the picture changes: instead of a data exchange between institutions, wallet-ownership verification may be required for the self-hosted side, depending on the jurisdiction. And below the threshold, the Travel Rule data exchange doesn't trigger at all — but that is not an exemption from compliance generally: sanctions screening and transaction monitoring never switch off.
For an embedded-wallet platform, the engineering consequence is simple to state: your wallet infrastructure needs to know which of your users' counterparties are VASPs, and needs a channel for structured data to travel with the transaction when the rule fires. That's a data-model question, and it's much cheaper to answer before launch than after.
03 — Does the custody model change your regulatory category?
More than any other single decision, yes.
If your platform (or your provider, on your behalf) holds users' keys, you are in custody territory: in most jurisdictions that means VASP registration or money-transmitter licensing, capital requirements, audited safeguarding of client assets, and — under regimes like MiCA in the EU — specific authorization as a crypto-asset service provider.
If wallets are genuinely non-custodial — keys or key shares derived and controlled so that the platform cannot unilaterally move user funds — the licensing picture is generally lighter. You are providing software, not safekeeping. KYC/AML obligations attached to your role as a business still apply, but the custody-specific regime usually does not.
The custody question isn't a technical detail buried in the architecture. It's the line that decides which regulator's rulebook lands on your desk.
This is why the honest answer to "custodial or non-custodial?" matters more than the marketing one. A "non-custodial" product where the provider can in practice sign alone is custodial in the eyes of an examiner — the label doesn't survive an audit, the architecture does.
04 — What will an auditor actually ask?
When the platform matures enough to face a compliance review, the questions are predictable. Being able to answer these five covers most of the ground:
- Show me the KYC tiers. Which users are verified, at what level, triggered by what — and where is that policy written down?
- Walk me through an alert. A screening hit or unusual transaction fires: who sees it, in what tool, within what time, and where is the decision recorded?
- Prove the custody claim. If you say non-custodial, demonstrate that no single party — including your provider — can move user funds alone.
- Show a Travel Rule transfer. One real example of a threshold-crossing transfer to another VASP, with the data that travelled alongside it.
- Who is accountable? A named person who owns the compliance program — not a shared inbox, not "the vendor handles it."
Notice that only one of the five is primarily about software. The rest are about process and ownership — which is exactly the split from question 01, showing up again at audit time.
05 — What a compliance-ready WaaS should hand you
Put together, a WaaS platform is compliance-ready for embedded wallets when it gives you: KYC/KYT endpoints you can wire into your own tiering policy, screening that runs on every transfer regardless of size, Travel Rule data support for the transfers that need it, and a custody architecture — like MPC with policy controls — whose non-custodial claim you can demonstrate rather than assert. CPAY's wallet infrastructure is built to that standard, with KYC/AML built in rather than bolted on.
Compliance doesn't get embedded along with the wallet — it gets redistributed. The infrastructure half can be bought; the program half is yours either way. The platforms that get this right aren't the ones with the most tooling, but the ones that knew which half was theirs from the start.
