> For the complete documentation index, see [llms.txt](https://slippay.gitbook.io/slippay-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://slippay.gitbook.io/slippay-docs/concepts/regulatory.md).

# Regulatory framing

SlipPay operates in a regulated payments space. Pretending otherwise is a product strategy that survives until the first enforcement action. This page is what we know, what we assume, and what's an open risk.

> **Disclaimer**: this is operational summary, not legal advice. For any specific deployment, consult a Brazilian payments lawyer.

## The Brazilian regulatory landscape (2026)

### Lei 14.478/2022 — Marco Legal das Criptomoedas

In force since June 2023. Defines virtual asset service providers (VASPs) in Portuguese as **Prestadores de Serviços de Ativos Virtuais (PSAVs)**. Establishes:

* registration requirement with a regulator (BCB designated)
* KYC obligations (Lei 9.613/1998 anti-money-laundering compatible)
* segregation of customer assets

Source: [Lei 14.478](https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2022/lei/L14478.htm)

### BCB Resoluções 519, 520, 521 (10 Nov 2025)

Implementing regulations. **In force 2 February 2026** (most provisions); foreign-capital reporting from 4 May 2026.

| resolution | scope                                                              |
| ---------- | ------------------------------------------------------------------ |
| 519        | governance and prudential requirements for SPSAVs (specific PSAVs) |
| 520        | minimum capital tiers (\~R$2M+ depending on activity)              |
| 521        | **classifies stablecoin trading as `operações de câmbio`** (FX)    |

The 521 reclassification is the load-bearing fact for SlipPay. It means: **any actor that mediates BRL ↔ USDC for a Brazilian user is operating inside the FX market** and must comply with FX rules (which require either a banco autorizado or a partnership with one).

Source: [Machado Meyer summary](https://www.machadomeyer.com.br/pt/inteligencia-juridica/publicacoes-ij/bancario-seguros-e-financeiro-ij/regulamentacao-de-vasps-no-mercado-de-cambio)

### Self-custody not banned, but VASP must KYC the wallet

Earlier drafts of the consultation tried to forbid stablecoin transfers to self-custody wallets. The final resolutions softened this to a KYC-of- counterparty requirement: VASPs may transfer to self-custody, but they must identify the wallet owner and document origin/destination of funds.

This is friendly to SlipPay's non-custodial model: the merchant address is still merchant-controlled; the VASP partner just needs to record who owns which address.

## What this means for SlipPay

### Non-custodial does NOT exempt from regulation

If SlipPay accepts BRL via Pix from a Brazilian buyer and delivers USDC to a Brazilian merchant, that flow is **operação de câmbio + virtual asset service** even if SlipPay never holds the BRL for more than a millisecond. The non-custodial framing applies to *funds*, not to *regulatory perimeter*.

This is the failure mode that kills naïve "we don't hold the money so we're not regulated" pitches.

### The partnership-with-VASP architecture

SlipPay's design is to **never operate the BRL leg directly**. Instead:

1. SlipPay is a **technology provider**: merchant API, hosted checkout, memo-matched on-chain settlement, webhook delivery.
2. A **licensed BR VASP** (Transfero, Bitso, or equivalent) handles the regulated leg: receives BRL via Pix from the buyer, performs KYC, conducts the FX operation, and mints USDC to the merchant's address on Stellar.
3. The buyer sees one flow ("pay with SlipPay"); the regulated leg is inside the anchor's perimeter, not SlipPay's.

```
        buyer (BRL)
             |
             v
       Pix to anchor
             |
             v   (anchor handles: KYC, AML, FX,
        anchor       BCB reporting, capital requirement)
             |
             v
       USDC to merchant Stellar address
             |
             v
       SlipPay listener observes (read-only)
             |
             v
       SlipPay fires webhook to merchant
```

SlipPay's role is the developer-experience layer: the merchant API, the hosted checkout UI, the order matching, the webhooks. The anchor's role is the regulated-flow leg.

## Status of the partnership

Drafted, not signed. See `docs/outreach/transfero.md` and `docs/outreach/bitso.md` for the partnership pitch templates. **Mainnet launch is gated on at least one anchor partnership being live.** Without it, SlipPay can technically run on testnet but cannot legally operate buyer-side Pix flow on mainnet for Brazilian users.

## What SlipPay does *not* need a license for

If SlipPay only:

* runs the merchant API and hosted checkout,
* observes Stellar payments via Horizon SSE,
* fires webhooks,
* charges merchants a SaaS fee (in USD via Stripe-equivalent, **not** in BRL via Pix),

then SlipPay is a software company, not a financial institution. The licensed leg sits at the anchor.

## What SlipPay *would* need a license for

If SlipPay decided to:

* accept Pix BRL into a SlipPay-controlled bank account,
* mint or hold USDC issuance,
* offer custody of merchant or buyer funds,
* run an FX desk,

then SlipPay would need to be either a SPSAV with R$2M+ minimum capital under Resolução 520 OR partner with a banco autorizado for the FX component. The 6–12 month licensing timeline is incompatible with the 2026-Q3 mainnet plan.

## Other jurisdictions (brief)

| jurisdiction  | relevant regulation               | impact                                                                |
| ------------- | --------------------------------- | --------------------------------------------------------------------- |
| US            | GENIUS Act (signed July 18, 2025) | clarifies USDC issuance; positive for SlipPay's USDC settlement claim |
| EU            | MiCA Phase 2 in 2026              | USDC and EURC are MiCA-compliant; EU merchants can legally accept     |
| LATAM (ex-BR) | varies country by country         | SlipPay does not specifically target other LATAM markets in v0.1      |

## Known regulatory open risks

1. **Anchor partner falling out of compliance**. If Transfero/Bitso loses its license, SlipPay's Pix-in flow stops. Mitigation: integrate with 2+ anchors from day one for failover.
2. **BCB issuing supplementary guidance** that classifies our flow more strictly. Mitigation: maintain a relationship with one of the major BR payments law firms (Demarest, Machado Meyer, or BMA) for fast-turn legal opinions.
3. **Stablecoin reclassification at MiCA or US level**. Lower impact; SlipPay's BR positioning is independent of these markets in v0.1.
4. **Tax obligations for merchants** receiving USDC. Brazilian Receita Federal expects merchants to declare crypto holdings monthly above R$30k. SlipPay doesn't file on the merchant's behalf; this is merchant's responsibility, surfaced in onboarding docs.

## What the marketing must not claim

Per memory `feedback_marketing_must_match_runtime`, every claim on the landing page should be verifiable in code. Specifically:

* ✘ "fully regulated" — not yet; depends on anchor partnership
* ✘ "licensed PSP" — not a PSP and not licensed
* ✘ "non-custodial means no regulation" — false under Res 521
* ✓ "non-custodial settlement" — true; precise claim about funds
* ✓ "technology layer on top of licensed VASPs" — true after partnership
* ✓ "BRL leg handled by licensed BR anchor" — true after partnership

When the partnership lands, the landing copy and this doc both update. Until then, the landing carries a "pre-launch" pre-suasion stamp and mainnet is gated.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://slippay.gitbook.io/slippay-docs/concepts/regulatory.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.