Published
9 MIN READ
Fintech software development on BaaS
Fintech software development on BaaS means building the app, the platform and the website of a company that offers accounts, payments or credit on top of the license of an institution authorized by the Central Bank of Brazil. Since Joint Resolution No. 16, that software has to show who provides the service and must be compliant by December 31, 2026.
The pages on fintech and white-label software I read in September 2026 don't cite the rule, and the legal analyses stop before the screen. This article translates the resolution into product requirements.
At Wama, this model came in through the portfolio: in 2026 the studio did the branding, the SaaS platform design and the website for Stric, infrastructure that lets companies operate as white-label digital banks. This is the product side of the guide on the obligation the rule already places on the institution's website.
What changes in fintech software development on BaaS?
Who is accountable changes, and so does what the software has to prove. Joint Resolution No. 16, of November 28, 2025, makes the authorized institution responsible for the reliability, availability, security and confidentiality of the service, even when the interface belongs to the partner company (art. 9).
The fintech still owns the brand and the experience, but the product now carries three obligations that used to be private agreements: identify the institution, pass operational data on to it, and accept that it may suspend the contract if the indicators fail. The rule has applied since December 1, 2025, and earlier contracts have until December 31, 2026 to comply (art. 22).
Provider, taker and customer
The rule separates three roles. The BaaS provider institution is the one authorized by the Central Bank: it provides the financial service and is accountable for customer identification, fraud prevention and anti-money laundering. The BaaS taker entity is the company that brings that service to its own customers, under its own brand and interface. The customer has a contract with both (art. 3).
The scope is closed. Under art. 4, only accounts (demand deposit, savings, prepaid and postpaid payment accounts), payments made through them, merchant acquiring and credit, from offer to collection, fall under BaaS.
The resolution also bans arrangements that architecture sometimes hides. The taker cannot hold the same type of account with two providers at the same time, except within the same conglomerate (art. 6), nor subcontract these services or receive customer funds tied to them in its own account (art. 8, XIV and XV).
What does the rule require of the screen and the documents?
The screen has to show who provides the service. Art. 14 requires the provider to ensure its identification appears accessibly and visibly in channels and interfaces, contracts, documents and payment instruments: app, website, receipt, statement, card and boleto (Brazil's bank payment slip).
The fintech's brand can keep appearing, and the article itself says so. What can't happen is the institution disappearing. Other points become interface requirements:
A notice that the taker does not act on behalf of the provider and, when applicable, that it is not authorized by the Central Bank (art. 8, § 2).
Clear fees, limited to those allowed for authorized institutions (art. 15), with no charges in the taker's own name (art. 8, XI).
Customer support that reaches the provider, which is responsible for customer requests even when the customer goes through the taker (art. 16).
This adds to the screens the Central Bank has already standardized for Pix. In 2025 Wama designed and developed the app for Cappta, a payment institution with a white-label digital account, with interfaces in Figma. In this kind of product, identifying who provides the service is a layout decision, not a footer.
What does the system need to deliver to the provider?
The fintech's system becomes part of the partner's controls. Before and during the contract, the provider checks whether the taker ensures confidentiality, integrity, availability and recovery of data and access control over personal data, and it needs visibility into the availability of the taker's platforms (art. 7).
As software requirements:
An availability check the provider can access.
Audit trails, metrics and indicators, tested at least once a year (art. 17).
Support indicators and system service levels, which can suspend the contract (art. 18).
Integration with the provider's customer identification and anti-fraud tools, since the policy is the provider's (art. 10).
An inventory of vendors that handle relevant data, because the taker gives notice before hiring a new one (art. 8, VI).
Retention of contracts for five years and of control records for ten (art. 21).
Item 5 touches the architecture: cloud, email, analytics and anti-fraud all count, and you have to define whose name the cloud accounts are in on day one. Code security follows a different rule, covered in the security rules for whoever develops the app.
At Milhas Pix, an airline miles marketplace with Pix payments, Wama covered the SaaS platform, management system, website and landing pages in 2025, down to the transaction tracking screens. When a product like that runs on a partner's license, that screen is also the data the institution will ask to see.
Name, brand and domain: what does Joint Resolution 17 change?
The brand is also covered now. Joint Resolution No. 17, of the same date, includes the trade name, the brand and the domain in the naming rules, and bans any term that suggests an activity without authorization, through similarity of form or sound and in any language (arts. 1 and 3). Coverage in the specialized press cited the obvious example: banco and bank.
In BaaS the effect comes from both sides. The provider cannot contract a taker with these terms in its name, unless the taker is also authorized (JR 16, art. 6, VI), nor keep a partnership whose presentation hides that the company is a partner (JR 17, art. 8). In Wama's reading, name and domain become a compliance decision and need to be settled before design, because redoing a brand after the app is published costs more than redoing a screen.
The calendar through the end of 2026
Date | What happens |
|---|---|
12/1/2025 | Joint Resolutions 16 and 17 published, already in force |
7/2/2026 | BCB Normative Instruction 754 creates the registry of takers in Unicad |
10/1/2026 | That registry takes effect, under BCB Normative Instruction 776 |
12/31/2026 | Deadline for bringing earlier contracts into compliance |
The October date came from BCB Normative Instruction No. 776, of September 17, 2026. The provider also has to list its takers on its own website, in a visible place (JR 16, art. 20).
Build on BaaS or get your own license?
BaaS is still the shortest path to launching accounts, payments or credit without your own authorization. The difference is that the shortcut now has written rules: the partner decides identification and anti-fraud, sees your indicators and can end the contract. Your own license trades that dependence for authorization and a compliance structure, a decision for the legal team before it is a product decision.
On BaaS, the first version is born with provider identification, audit trails and integration with the provider's tools: it's the method for taking the platform from first scope to operation with one extra layer. In Wama's projects, AI sped up the building, not the deciding, and the total timeline didn't change. In fintech that matters more, because roles, brand and the data path need to be settled before the first screen.
How to choose who will build it
Ask the vendor whether they know where the rule touches the product. Before you sign:
Check in the prototype where the provider appears on each screen, receipt and contract.
Ask for the list of vendors and infrastructure accounts, and whose name each one is in.
Confirm that the system exposes availability, audit trails and indicators to the partner.
Check that onboarding and anti-fraud use the provider's tools.
Put in the contract who keeps the code when the contract ends.
At Wama, the project is transferred to the client's account, so the client owns the website, the domain and the account, and anyone who switches vendors takes everything with them. On BaaS this carries more weight, because the partner needs to know where the data is.
Common mistakes
Hiding the partner in the footer or the terms of use. Art. 14 requires visible identification in interfaces and documents.
Using banco or bank in the name or the domain. An unauthorized taker is barred from contracting BaaS that way.
Building an onboarding flow parallel to the provider's. The customer identification policy is the provider's.
Receiving customer money in the fintech's own account. Art. 8 prohibits it.
Leaving compliance for December. Screens, contract and integration change together.
Frequently asked questions
What is BaaS according to the Central Bank of Brazil?
It is an arrangement in which an authorized institution provides financial or payment services to another company's customers, through that company. Joint Resolution No. 16 limits the scope to accounts, payments through them, merchant acquiring and credit, and leaves regulatory responsibility with the authorized institution.
When does a BaaS fintech need to comply by?
Contracts that already existed on December 1, 2025 have until December 31, 2026. New contracts are born under the rule. The registry of partner companies in Unicad, done by the authorized institution, takes effect on October 1, 2026.
Can the fintech use its own brand in the app?
Yes. The rule requires the provider institution to appear accessibly and visibly, but says this does not prevent the partner company from being identified. The two brands coexist, as long as the fintech's name doesn't suggest a regulated activity without authorization.
Who handles customer identification at a BaaS fintech?
The provider institution. The policy and controls for customer identification, fraud prevention and anti-money laundering are the provider's. The fintech can perform ancillary tasks, always with the tools the provider supplies, without transferring the responsibility.
How much does fintech software development cost?
It depends on the number of flows and how much of the product is regulated. As a reference, Wama's general range for SaaS and custom software goes from US$ 4,000 to US$ 20,000, up to US$ 40,000 depending on complexity. What moves that number is in the investment range for a first version.
If your fintech operates on a partner's license and the app still doesn't show who provides the service, the deadline is December 31. Talk to Wama and bring your current flow to the first meeting. The reading of the rule here is a product reading: validate each point with the partner's legal and compliance teams.
