Who owns compliance when you integrate a crypto on-ramp API? KYC, KYB, KYT, and holds

A crypto on-ramp is generally regulated as a money transmitter or a virtual asset service provider, so it must run KYC, AML, sanctions screening, and transaction monitoring on everyone who pays in. When you integrate one through an API, the provider runs those checks. You still own the data you collect, the customers you bring, and your own licensing questions.

This article is general information, not legal advice. Compliance obligations depend on your jurisdiction, your business model, and your contract with the provider. Talk to counsel before you rely on any of it.

Key takeaways

• The provider is the regulated party for the conversion. It verifies identities, screens sanctions, monitors transactions, and files reports.
• You collect the data, keep it accurate, and make sure only verified customers pay through your account.
• Every party whose money moves needs to be visible to the provider. Pooling unregistered end customers under your account is nesting.
• Holds are part of the system. Plan who answers a request for information, and how fast.
• Whether you need your own license depends on whether you ever take possession of the money. That's a question for a lawyer, not a blog post.

What compliance checks does a crypto on-ramp run?

Seven checks, each with a different job.

KYC and KYB answer "who is this?". KYT answers "does this payment make sense for them?". What is KYB goes deeper on business checks, and the travel rule for off-ramps covers thresholds by country.

What do regulators expect from on-ramps?

Four primary sources set the frame. Read them directly; summaries, including this one, drop detail.

• FinCEN (US). The 2019 guidance on convertible virtual currency treats businesses that accept and transmit virtual currency as money transmitters, with registration, AML program, recordkeeping, and reporting duties. You can check a provider's registration in the MSB registrant search.
• OFAC (US). The sanctions compliance guidance for the virtual currency industry expects screening of customers and wallet addresses, and a risk-based sanctions program.
• FATF (global). The updated guidance on virtual assets and VASPs sets the standard most countries copy: customer due diligence, monitoring, and the travel rule.
• EU. MiCA requires crypto-asset service providers to be authorized, and the Transfer of Funds Regulation applies the travel rule to crypto transfers with no minimum amount.

The pattern is the same everywhere: know who's paying, watch what they do, screen against sanctions, keep records, and report what looks wrong. What is a VASP explains how the FATF definition maps onto local licenses.

Who is responsible for what when you integrate an on-ramp API?

The provider runs the regulated checks. You run your business honestly on top of them. The split below is typical; your contract and your jurisdiction decide the real one.

Two rows trip people up. The first is data quality: the provider verifies what you send, so a sloppy onboarding form becomes a compliance problem downstream. The second is the last row, covered next.

What is nesting, and why do on-ramps prohibit it?

Nesting is moving money for a party the provider can't see. If one customer's account carries deposits that economically belong to many other businesses or people, and the provider never onboarded them, the structure is nested.

Signs of nesting:

• Funds in the account belong to someone other than the onboarded customer.
• Invoices or contracts name a different entity than the account holder.
• One account collects for several underlying businesses.
• Each sub-account or virtual account represents a different third party's money.

Regulators treat this as a way to hide who's really behind a payment, which is why providers prohibit it. The fix is visibility: register each end customer with the provider, or have the business that serves them onboard as its own direct customer.

Do you need your own license if you use an on-ramp API?

Maybe. It depends on what your product does with the money, and only a lawyer who has read your flow of funds can answer it.

The questions that usually decide it:

1. Does money ever land in an account you control, even for a moment?
2. Do you hold stablecoins or fiat on behalf of users?
3. Do you set the exchange rate, or does the provider?
4. Are your users individuals, businesses, or both, and in which countries?

A product that only passes data to a licensed provider, with funds moving straight from the payer to the provider and stablecoins straight to the user's own wallet, sits in a different place than one that collects funds first. Do merchants need a license to accept stablecoins walks through a related version of the question.

What does a good on-ramp compliance flow look like?

Six stages, in order:

1. Onboarding. Collect the data, accept the terms, run KYC or KYB.
2. Risk scoring. Higher-risk countries, business types, or structures get enhanced review.
3. Limits. Each verification tier gets per-transaction, daily, and monthly limits.
4. Monitoring. Every payin is screened and scored as it happens.
5. Holds and requests for information. Flagged payments pause for a human, who may ask you questions.
6. Decision. Release, refund, or escalate, and keep the record.

The stages after onboarding are where integrations break. A product that handles approval but has no screen for "in review" will generate support tickets on day one. Real-time transaction monitoring shows a flagged payment from start to finish.

How should you think about compliance across countries?

Don't build a table of rules per country. It goes stale. Build a checklist of what varies, and ask the provider how it handles each one in your markets:

• Licensing regime. Money transmitter, VASP, payment institution, or something new, like Brazil's VASP rules covered in PSAV Brazil explained.
• Identity documents and tax IDs. CPF and CNPJ in Brazil, CUIT and CUIL in Argentina, NIT in Colombia.
• Enhanced review. Which countries trigger manual checks.
• Travel rule thresholds. These differ, and some markets apply the rule with no minimum.
• Data protection. Where identity data is stored and who processes it.
• Stablecoin rules. Some markets regulate the token itself, like the US under the GENIUS Act and the EU under MiCA.

What 12 questions should you ask a provider about compliance?

1. Which licenses or registrations do you hold, in which entities, and where can I verify them?
2. Who verifies identity: you, or a vendor you rely on?
3. Which fields and documents are required for KYC and for KYB?
4. How long do automated and manual reviews take?
5. Which countries trigger enhanced review, and which can't onboard at all?
6. What are the default limits per tier, and how do customers raise them?
7. Do you screen wallet addresses as well as people?
8. How are flagged payments held, and how will you contact us?
9. How long do we have to answer a request for information, and what happens if we don't?
10. Can we answer requests for information through the API?
11. How do you handle end customers of our customers?
12. Which business activities do you prohibit, and which need extra disclosure?

Write the answers into your vendor file. Stablecoin payments provider due diligence has the wider set of 30 questions.

How does BlindPay split compliance with you?

BlindPay handles the compliance layer: you collect the data, and BlindPay verifies it. Every payment flows through a verified customer.

• KYC and KYB levels. KYC Standard for individuals is automated and takes about 60 seconds. KYC Enhanced is required for individuals from high-risk countries and is reviewed manually, as is KYB Standard for businesses, in 3 hours to 1 business day.
• Every customer is registered. Every customer on your platform must be registered as a customer in BlindPay. If one of your customers is itself a money transmitter, its end customers must be registered too.
• Terms of service. Each customer accepts BlindPay's terms before onboarding, and again when the terms change.
• Limits per tier. Payins and payouts have separate limits. Per transaction, KYC Standard starts at $10,000, KYB Standard at $30,000, and KYC Enhanced at $50,000, with a limit-increase flow backed by documents.
• Transaction monitoring with on-hold review. BlindPay's KYT flags suspicious payins and payouts and puts them on_hold. The compliance team reviews each one and may send a request for information. If it isn't answered within 24 hours, the payment may be refunded to the sender.
• Requests for information through the API. When a customer's review needs more data, a customer.update webhook signals compliance_request, and you fetch and answer the request with the RFI endpoints.
• Nesting rule. You can't move money through your account for parties BlindPay can't see. A business rejected for nesting can onboard as its own BlindPay instance, at no extra cost, and register its customers there.

The details are in the docs for KYC requirements, on-hold transactions, and nested payments.

When BlindPay is the right fit: you want compliance handled inside the API, with KYC, KYB, monitoring, and holds visible as statuses and webhooks you can build screens around. When it isn't: you want to run your own identity verification and only buy liquidity, or your business falls under BlindPay's prohibited activities.

What to do next

Draw your flow of funds on one page: where the payer's money goes, who holds it at each step, and whose wallet the stablecoins reach. Mark who verifies each party. Take that page to your provider and your lawyer. Most compliance surprises show up as a box on that page that nobody owns.

If you're still choosing a provider, business vs consumer crypto on-ramps explains why business on-ramps verify more than consumer ones. Integrating a crypto on-ramp API shows where the KYC, hold, and request-for-information statuses appear in code.

This article is general information, not legal, tax, or financial advice. Regulations change, and obligations depend on your jurisdiction and contracts; confirm with qualified counsel.