Published
14 MIN READ
Fintech website design: what the law requires
Building a fintech website has a layer no other corporate website has: regulatory obligation. A licensed payment institution must state that status on its own channels and disclose on its website which payment services it provides. Copy and design come after that.
The Brazilian pages competing for this search term don't mention it. Of the four I read in September 2026, two are agency sales pages, one is a pricing article last updated in November 2025, and one is a generic website-building post with the title swapped. None of them cites the Central Bank of Brazil.
At Wama, fintech isn't new territory: Stric, Cappta, Milhas Pix and Biz are in the portfolio, across websites, platforms and apps. That's what separates this guide from the scope of a corporate website with no regulatory layer, where the worst consequence of a content mistake is commercial, not a penalty.
What changes when building a fintech website?
What the website has to prove. A services website sells competence; a fintech website has to show that the company is legally allowed to do what it advertises, that the user's money sits somewhere identifiable, and that someone is accountable on the other side. Trust here is a requirement, not a differentiator.
Who reads it changes too. A fintech website visitor tends to be more skeptical than average, because they've seen returns promised that never existed and because the cost of a mistake is their own money. Vague copy doesn't get past that filter, and no visual trick makes up for a claim the reader can't check.
What stays the same as any website
Information architecture, speed, content the team can edit, SEO and conversion all still apply. Nothing that applies to any website that needs to convert stops applying because the company is a fintech. The quality bar is the same, and the floor is higher.
What is specific to the industry
Three things: disclosure obligations set by regulation, an audience that checks before it trusts, and a product that almost always continues after the website, as an app or a platform. All three need to be in the brief that asks the right questions before design, because ignoring any of them produces a beautiful website that gets in the way of operations.
What the law requires from a payment institution's website
BCB Resolution No. 80, of March 25, 2021, issued by the Central Bank of Brazil, states in Article 5, paragraph 4, that a payment institution must clearly state its status as a payment institution on its communication and customer service channels, and disclose on its website the payment service types it provides.
This isn't a best-practice recommendation. It's regulatory text, and paragraph 5 of the same article gave already licensed institutions until December 31, 2022 to comply. A website that doesn't say what the company is and what it does is breaking the rule, however well designed it is.
Which service types the website must disclose
The list comes from Article 6, item III, of Law No. 12,865 of 2013, which defines a payment institution by the activities it carries out. There are eight, and the website has to make clear which of them the company provides.
Service type defined by law | How it usually shows up in the product |
|---|---|
Depositing or withdrawing funds in a payment account | Deposits and withdrawals in the app account |
Executing or facilitating payment instructions | Transfers and Pix, Brazil's instant payment system, inside the product |
Managing a payment account | The digital account itself |
Issuing a payment instrument | The company's own card, physical or virtual |
Accrediting the acceptance of a payment instrument | Card machines and payment capture |
Executing fund remittances | Sending money between people |
Converting and managing electronic money | Digital wallet balance |
Others designated by the Central Bank | Depends on the payment arrangement |
Turning those eight rows into a page a customer understands is content work, not legal work. That's where most websites in the industry go wrong: they copy the regulatory text, publish a paragraph nobody reads, and consider the obligation met because the sentence is there.
Not every fintech is regulated: who needs what
The obligation above applies to licensed payment institutions. A good share of Brazilian fintechs aren't one: they operate on a partner's license, in an infrastructure-as-a-service model. In that setup, the licensed institution carries the obligation, and the fintech's website has to make clear who that institution is.
Stric, a Wama client since 2021, is exactly that kind of company: infrastructure that lets other companies operate as digital banks in a white-label model. When a client's product is someone else's license, the website has to name the regulated party, and that changes the content architecture before it changes the layout.
This is where the project stops being a corporate page and becomes the point where operations start depending on what's live. The practical difference: a wrong sentence on a consulting firm's website costs a meeting; on a fintech's website, it costs a reply to the regulator.
Three setups and what each one asks of the website
The company's regulatory setup defines how much the website must state. The table sums up the three most common ones, and the question the project must answer before the first screen is which one the company falls into.
Setup | What the website must make clear |
|---|---|
Licensed payment institution | Its own regulatory status and the service types it provides |
Fintech operating under a partner's license | Which licensed institution is responsible for the account and settlement |
Financial software with no custody of funds | That the company doesn't hold or move the user's money |
The third case is the most poorly handled on Brazilian websites. Companies that only offer financial management software often communicate as if they were banks, attract the wrong questions, and then spend support time explaining that they don't hold anyone's money.
Which pages does a fintech website need?
Beyond the usual corporate pages, a fintech website needs pages that answer whoever is assessing risk. The structure below is the one that repeats across projects in the industry, with the regulatory layer added to what already applies to the page structure of a subscription product.
Page | Why it exists |
|---|---|
Home | Say what the company is, in one sentence, with the regulatory status visible |
Payment services | Meet the service type disclosure, in customer language |
Security | Explain what protects the money and the data, without jargon |
About and governance | Show there are people and structure accountable |
Fees | Keep the price from showing up only in the contract |
Help center | Reduce tickets and support the required customer service |
Customer service and ombudsman | Give complaints an address before they become lawsuits |
Legal documents | Accessible terms, privacy policy and contracts |
These pages are also what a language model reads when someone asks whether the company is trustworthy, which brings the project closer to being found by people who ask an AI instead of typing into a search engine.
How does the website build trust with people about to move money?
By making everything verifiable. People evaluating a fintech before opening an account look for three things: who is behind the company, under which license it operates, and what happens if something goes wrong. A website that answers that in two clicks converts better than one that promises security with adjectives.
What is verifiable and what is just a promise
Legal name, CNPJ (the Brazilian company registration number), regulatory status and the name of the partner licensed institution are verifiable. A generic security badge, customer numbers without a source and a sentence about cutting-edge technology are not. The first group supports a decision; the second fills space.
The complaint channel is content, not footer
Anyone looking for a fintech's customer service channel already has a problem. A clear address, with a stated response time and a path to the ombudsman, resolves complaints before they reach a public platform or the regulator. It's the cheapest page to build and the most expensive one not to have.
Performance is also a trust signal
A fintech page that's slow to open on a phone loses before it makes its case. It's worth understanding what the performance score actually proves, because the metric is a means, not an end: what matters is the page responding fast for someone deciding where to put their money.
What changes in the app compared to the website?
The website persuades, the app operates. On the website the visitor reads; in the app they sign up, submit documents, approve transactions and check balances. That turns the project into a product, with error states, access roles and a sign-up flow that must verify identity before allowing any transaction.
In 2025, Wama delivered the design and development of the app for Cappta, a payment institution that offers payment capture and digital accounts in a white-label model. In this kind of product, the sign-up screen isn't a form: it's where the company meets an obligation and where the user decides whether to continue.
Sign-up is the most expensive part of the app
That's where identity verification, document capture, liveness checks and rejections are concentrated. Every step loses people, and every step removed adds risk. Designing this stretch is the same work described in the path between creating an account and the first useful action, with one extra constraint: part of it can't be cut.
After sign-up comes daily operation, and that's where the moments that decide whether the user stays apply: permissions, empty states and what the app shows when a transaction fails.
Website, platform and app: where each one ends
They're three projects with different scopes and timelines, and mixing them up is the main cause of blown budgets in the industry. The website is public and sells. The platform is behind a login and operates. The app is the same product in the end customer's hand. Each has its own maintenance cycle.
On the Milhas Pix project, in 2025, Wama covered that whole range: platform, management system, website and landing pages, from the acquisition page to the screens for managing offers and tracking transactions. That's the exception, not the rule, and it only makes sense when the product and acquisition are born together.
When the conversation moves from the page to the product, the topic becomes taking the platform from the first scope to scale, with architecture decisions the website doesn't impose.
Who is responsible for user data?
The fintech, always. Under the LGPD, Brazil's data protection law, the controller is whoever makes decisions about the processing and the processor is whoever processes the data on the controller's behalf. The agency that builds and runs the website or app is a processor: hiring one doesn't transfer the responsibility of whoever owns the product.
This weighs more in fintech because the data is financial and the volume is high. The information security guide from the ANPD, Brazil's data protection authority, published in October 2021, recommends a written policy covering backups, passwords, access, data sharing and software updates, with periodic review.
The split of responsibility and the ownership of infrastructure accounts are detailed in controller, processor and whose name the accounts are in, which applies in full to fintech projects.
How much does a fintech website cost and how long does it take?
It costs the same as a corporate website of similar size, plus the regulatory content work. At Wama, a corporate website runs between US$ 2,000 and US$ 8,000 and takes four to six weeks, based on 50 to 100 quotes. A digital product is a separate budget, between US$ 4,000 and US$ 20,000.
What pushes the project to the top of the range
Number of unique pages, who writes the copy and custom animation are the three items that move the budget most. In fintech, the second weighs more: describing eight service types without slipping into legalese is copywriting work, and copywriting is a scope item. The general comparison is in what the Brazilian market charges for a professional website.
What causes the most delays
Content that doesn't arrive, slow approvals and scope changes after the design is signed off. In fintech there's a fourth: legal review of the copy, which usually comes in late. When the project includes a product, the schedule also depends on what weighs on the budget of a first version.
Agree on the legal review at the start, alongside the brief, not in the week of launch. When the copy for the service pages comes back from legal after the layout is locked, the rewrite breaks the layout and the project loses days on visual adjustments that have nothing to do with the approved content.
How to choose who will build it
Look for someone who has delivered in the industry and knows what the regulation requires without you having to explain it. A fintech portfolio isn't vanity here: it's the difference between a vendor who asks which license you operate under and one who finds out in the third round of revisions.
At Wama, one person follows the project from brief to deploy, and the project is transferred to the client's account, with the subscription on their card. In fintech this matters more than in any other industry: the domain and access must be under the regulated company's CNPJ, not the vendor's.
Five fintech-specific questions
Who writes the copy for the payment service pages and who does the legal review.
How the vendor handles disclosure of the regulatory status on the home page and in the footer.
Whose name the domain, repository and infrastructure accounts are in.
What happens to the website during an audit or an investor due diligence.
Whether the scope includes only the website or also the logged-in area, and where each one ends.
The question list in the general yardstick for comparing website proposals still applies, plus code ownership at the end of the project when the scope includes a platform.
Common mistakes on fintech websites
The list below comes from the pattern that repeats across pages in the industry, and almost all of it has the same origin: the website was treated as a brand piece when it's also a compliance piece. The seven items cost little to fix before design and a lot after the page is live.
Leaving out the regulatory status. The regulation requires it to appear clearly on communication channels, not hidden in the footer.
Copying the regulatory text onto the page. It meets the letter and loses the reader. Translating it is part of the scope.
Calling a payment account a bank account. They're different things in the law and in the product.
Promising security with adjectives. Without saying what is done, the sentence works against you.
Keeping fees only in the contract. Anyone who can't find the price on the website assumes the worst.
Treating the app as phase 2 of the website. They're separate projects, with their own scope and maintenance.
Registering the domain and access in the agency's name. In a regulated company, that becomes an audit problem.
Most of these mistakes die in the brief, before design, not in a revision round after the website is already live and the team found the problem through customer support.
Frequently asked questions
Does every fintech need to say on its website that it's a payment institution?
Only licensed payment institutions. BCB Resolution No. 80, of 2021, requires that status to appear clearly on communication channels and the website to disclose the service types provided. A fintech operating under a partner's license should make clear which institution is responsible.
How much does a fintech website cost in Brazil?
In the range of a corporate website of similar size. At Wama, a corporate website runs between US$ 2,000 and US$ 8,000, based on 50 to 100 quotes, and a digital product project goes from US$ 4,000 to US$ 20,000. Regulatory content comes in as a scope item.
Can you build a fintech website in Framer?
Yes, and that's what Wama did for the websites of Biz, in 2022, and Stric, in 2026, both in Framer. The platform handles corporate websites, blogs and content pages. A logged-in area, accounts and transactions are product, and that's a different project.
Do the website and the app need to be built by the same vendor?
No, but someone has to be responsible for consistency between the two. Website and app share brand, language and promise, and any mismatch between them shows up fast for the user. When the vendors are different, define in writing who decides what in case of conflict.
What does the website need to say about security?
What is verifiable: how data is protected, who is responsible for incidents and where to complain. The ANPD's information security guide recommends a written policy covering backups, passwords, access and software updates. Publishing what exists is worth more than a generic promise.
If you're about to get a fintech's website, platform or app off the ground and want all this in writing before design, talk to Wama and ask for a detailed proposal.
