Relying on a client's KYC (know your customer, the verification of an individual) in Brazil means a payments provider accepts identity checks the client already ran, instead of repeating them. The Central Bank's anti-money-laundering rule asks each institution to run its own identification procedures, so what a provider can reuse is the evidence: documents and a liveness check.
A platform does not want to ask each end user for the same selfie twice, and a provider cannot hand its own duty to someone else's database. The useful question is which pieces of a verification travel.
This post covers what the rule says, who stays responsible, what a provider can reuse and how, why Lumx does not reuse a company's KYB (know your business, the verification of a company and its owners), and who reports operations to the tax authority and the financial intelligence unit. Product behavior comes from the Lumx docs read on November 6, 2026.
What relying on KYC means in Brazil
The main Brazilian text on customer identification for institutions the Central Bank authorizes is Circular BCB 3.978 of January 23, 2020, read on November 6, 2026. Article 16 requires identification procedures that verify and validate the customer's identity, with a minimum set of data. Article 23 forbids starting a business relationship before identification and qualification are finished, with a thirty-day allowance only for missing qualification data. For companies, Article 24 requires the analysis of the ownership chain down to the natural person who is the beneficial owner. The text has no article that lets an institution count another party's identification as its own, so what a provider does with a client's file is part of its own procedure, not a replacement for it.
Whether the Circular reaches a provider in the transition regime under Resolution BCB 520/2025 is not covered here. The statute behind it is Law 9.613 of March 3, 1998, which lists the duties of the persons it covers, starting with identifying customers. Law 14.478 of December 21, 2022 amended Article 10, II so the transaction record names virtual assets. We walk through that reading in AML rules for a stablecoin fintech.
In practice reliance is narrow: it saves the customer a repeated step, not the provider's review or its monitoring after onboarding. The three checks are compared in KYC, KYB and KYT.
Who stays responsible when a provider reuses KYC
Both sides stay responsible for their own part. The client answers for its own licence, AML program and customers. The provider answers for the operations it carries and the customers it accepts.
Responsibilities when a client's KYC is reused, as a general split. The exact allocation depends on each licence and each contract.
Obligation | Client that onboarded the user | Provider that reuses the KYC |
Collecting the user's data and evidence | Yes | Receives it and checks it |
Deciding the evidence is enough for its own purposes | Yes, for its own program | Yes, for its own program |
Monitoring the transactions it carries | Its own platform | The operations on its rails |
Answering requests for information on a held payment | Holds the customer relationship | Sends the request |
Reporting to authorities | Its own operations, if it is itself a VASP in Brazil | The operations it carries, under its own status |
Get the split in writing before launch.
I recommend that a platform treat a reused KYC as a faster way to hand over documents, never as a way to hand over the duty. I would keep the platform's own program running as if the provider's review did not exist, and I would ask the provider, before launch, which parts of the verification it repeats even after a share is imported. A platform that cannot answer that question has not read the integration, whatever the contract says.
A platform that is not itself a VASP (virtual asset service provider) should confirm with its own counsel whether any filing duty falls on it.
What can a provider reuse from a client's KYC?
The documents and the liveness check are the part that travels. The questionnaire, the terms and the company-level checks do not. The table is the item-by-item list from the Lumx KYC reuse guide, read on November 6, 2026.
What a Sumsub share covers and what remains on Lumx, for an individual customer. Source: the Lumx KYC reuse guide and identity verification page, read on November 6, 2026.
Item | Reused through the share | Still done on Lumx |
Identity documents | Yes, imported from the client's Sumsub applicant | No new upload |
Liveness check | Yes, imported with the applicant | No new check |
Name, tax ID, birth date, country, email | Sent in the create-customer request, and must match the applicant | Sent once through the API |
Terms of service | No | The customer accepts the Lumx terms |
Additional information (phone, address, occupation, income, source of funds, counterparties) | No | Sent through the API for each customer |
Starting the verification | No | Started explicitly, because there is no liveness step to trigger it |
Business customers (KYB) | Not available | Standard business verification |
If the Sumsub applicant is missing something, Lumx may still require it. The minimum data is the same as for any customer created through the API.
On Lumx, the documents and liveness are imported from the client's Sumsub applicant when the share is sent in the create-customer request. The customer then completes the terms and the additional information, and the verification runs until the status reaches APPROVED.
How sharing a verified Sumsub applicant works
Sharing is a hand-off between two accounts at the same verification vendor. The client generates a Sumsub share token, a one-time authorization to import a verified applicant, and the provider sends it with the create-customer request to import the applicant's data.
Three conditions apply. Both sides must agree to share applicant data on Sumsub before anything can be exchanged. The authorization is single-use and expires after a time set when it is generated, so each attempt needs a fresh one. And the customer data in the request has to match the applicant's, or the import fails.
The alternative is sending the data by API with no share: the customer goes through the standard individual flow, which needs no agreement between the two accounts.
A Brazilian individual arrives with a CPF (the Brazilian individual taxpayer ID), an identity document and a selfie already on file. The reuse saves the last two. It does not change who the customer is or what the provider monitors afterwards.
Two questions follow. The first is size: Lumx's standard individual verification targets about 60 seconds, automated, as a target, not a promise, so the share saves a document upload and a selfie, not days of review. The second is data protection: sending an applicant's data from one company to another needs a legal basis under Brazil's data protection law (LGPD), and the client should check with its counsel that its own privacy notice covers it.
On Lumx, the basis the docs require is a data-sharing agreement between the client and Lumx on Sumsub, set up with the compliance team. Sending the share is optional: leaving it out sends the customer through the standard individual verification flow.
Why a company's verification is not reused on Lumx
A company is not a larger individual. Its verification covers the entity, the ownership chain and the people who control it. In Brazil that centres on the CNPJ (the Brazilian company taxpayer ID) record and the articles of incorporation, and the chain has to reach natural persons. We explain the file in what KYB is, and the step-by-step onboarding in the KYB onboarding flow.
A share carries one applicant. A company file is a set of linked applicants: the representative, every beneficial owner and every shareholder above 25 percent, each with an identity document and a proof of address. The reason compliance teams usually give for not reusing a KYB is that the provider would be accepting the client's judgement about who owns a third company, with no way to check it. That is a reason, not a rule: other providers may decide differently.
On Lumx, a business customer always goes through standard business verification, whoever sent it. A share sent for a business customer is rejected. Lumx targets one business day for standard KYB, as a target rather than a promise, and a customer that needs higher limits goes through enhanced verification with the compliance team.
Who reports operations to the Receita and the COAF
Brazil has two reporting channels that touch virtual assets: the tax authority and the financial intelligence unit. The Receita Federal's crypto-asset page, updated August 27, 2026, lists two instruments: Normative Instruction RFB 1.888 of May 3, 2019, with its filing manual on reporting operations with crypto-assets, and the DeCripto declaration, created by Normative Instruction RFB 2.291 of November 14, 2025. The Central Bank adds a third: Article 82-A of Resolution BCB 521 of November 10, 2025 requires the information in Annex II-A on virtual-asset service operations by the fifth day of the month after the operation, for the institutions it covers. The COAF receives communications under Law 9.613/1998.
Which of those a given business must file depends on what it is. We cover who falls under the regime in Brazil's stablecoin rules for 2026 and the PSAV regime. Reliance on a client's KYC does not move any of it: each institution reports under its own status. A platform that is itself a VASP in Brazil reports its own operations.
On Lumx, the reporting of customer operations is Lumx's, as the VASP (see what a VASP is) that filed its SPSAV request and operates under the transition regime of Resolution BCB 520 of November 10, 2025. Lumx reports under IN RFB 1.888/2019, IN RFB 2.291/2025 (DeCripto) and the Annex II-A report to the Central Bank. A client that is itself a VASP in Brazil reports its own operations. An external transfer in Brazil is identified and reported to the COAF, and when a transaction needs a hold, the customer receives an RFI (request for information, a compliance hold that asks for a document before a transaction clears).
When not to rely on a client's KYC
Reliance is the wrong tool in four cases.
The user is a company. A KYB file is not transferable evidence, as above.
The evidence is old or incomplete. An expired document, a missing page or a name that differs between the ID and the data sent will fail the import or come back as an RFI.
The flow of funds is unclear. If the user is paying or collecting for someone who was never onboarded, a clean KYC does not fix that. We cover where that line sits in paying third parties in Brazil.
The use case is restricted. A verified identity does not pre-approve an activity. The list of what providers refuse is in restricted use cases in Brazil.
A platform unsure whether one of these applies should run the standard flow.
What this looks like on a Pix payout with Lumx
Take a Brazilian marketplace that already verifies its sellers on Sumsub and wants to pay them out by Pix (Brazil's instant payment system, run by the Central Bank).
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
Each seller is one Lumx customer, with verification of their own. For an individual seller, the marketplace can send the Sumsub share when it creates the customer, once the data-sharing agreement is in place. The seller accepts the Lumx terms, the marketplace sends the additional information, and the marketplace starts the verification. Until the status reaches APPROVED, the seller cannot move money. The marketplace can read that status from the customer record or subscribe to webhooks.
A seller that is a company goes through business verification instead. If something is wrong, the customer moves to RFI and the status reason says which document or field is at issue. The customer's country needs to be on the supported countries list, and the payout itself runs on the rails described in Lumx's global payments product.
What the marketplace does not get is a way around its own program. It keeps the relationship with its sellers and whatever its own licence asks of it.
Methodology and sources
Product behavior was read on November 6, 2026 on the Lumx docs pages for KYC reuse, identity verification, business verification, individual verification, create a customer and request for information. The docs do not describe regulatory reporting. The SPSAV filing is public, and the statement that Lumx reports customer operations to the Receita and the COAF is Lumx's own, confirmed by Lumx on November 6, 2026.
Circular BCB 3.978 of January 23, 2020 was read on November 6, 2026 in the PDF published on the Central Bank normative site, in the version with Resolution BCB 119/2021. The statement that it has no article on reliance comes from reading its identification chapter and third-party provisions, not from a legal opinion.
The Receita Federal statements were read on November 6, 2026 on the Receita Federal crypto-assets page, the IN RFB 1.888/2019 acts page and the DeCripto page. Those pages list the instruments and their titles. The text of the two Receita instruments was not read (normas.receita.fazenda.gov.br serves only a script shell), so this post does not describe who must file with the Receita or when. Article 82-A and Annex II-A of Resolution BCB 521 were read on the Central Bank norms API on November 6, 2026.
Law 9.613 of March 3, 1998 and Law 14.478 of December 21, 2022 are cited by number and date without a link. planalto.gov.br did not answer on November 6, 2026, so the Article 10 wording follows the reading in our earlier post on September 24, 2026. Resolution BCB 520 was read on the same API only to confirm its date and Article 88.
Verified on November 6, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Vik Molina on Unsplash.
Can a payments provider rely on a client's KYC in Brazil?
Partly. A provider can reuse the evidence a client collected, such as identity documents and a liveness check, but Circular BCB 3.978 asks each institution for its own identification procedures and has no article that replaces them. On Lumx, an individual can be onboarded through a Sumsub share under a data-sharing agreement, which reuses documents and liveness but not the questionnaire.
Does Lumx accept KYC or KYB that a client already completed?
For individuals, yes, through a Sumsub share, after both sides agree to share applicant data. For companies, no. A business customer goes through Lumx's standard business verification, and a share sent for a business is rejected.
Does reusing a client's KYC move the legal responsibility to the client?
No. See the Circular summary above. On Lumx, a customer imported through a share still accepts the terms, sends additional information and must reach the approved status before moving money.
Who reports customer operations to the Receita Federal and the COAF?
Each institution reports under its own status. On Lumx, the reporting of customer operations is Lumx's, under IN RFB 1.888/2019, IN RFB 2.291/2025 and the Annex II-A report, as the provider that filed its SPSAV request and operates under the transition regime. A client that is itself a VASP in Brazil reports its own operations.
What does the customer still have to do after the KYC is reused?
Accept the provider's terms, send the additional information such as address, occupation, income and source of funds, and wait for approval. On Lumx, the verification is started explicitly through the API once those steps are done.
