CPF SeguroProduct · three surfaces at once7 min read

Fraud protection running under another company's brand.

Fraud protection in three places: the app store, a partner's app, and the operator's desk

Client: CPF Seguro
Period: 2021 to now
Role: Senior Product Designer
Scope: App, partner app and panel

The home screen of the standalone appThe ID status takes the whole top of the screen. People buying fraud protection arrive afraid, and their first question is whether they are protected right now. Below it sits the highest-consequence action in the product, then the history of who used your name and where.

Product in production. Product Designer at Diletta Solutions, the software company where I work, from November 2021 to today. Senior since 2025.

+34%: completion on sign-up inside the partner’s app, after the six-screen flow.
3: surfaces live on one system: the store, a partner’s app, and the operations panel.
88: screen parts with their options, values and defaults declared in one place.
22: flows audited by a program, with readable output.

00 File


Product	CPF Seguro · identity protection
Where it shows up	its own app in the store · inside a partner's app · operations panel
Role	Product Designer, Senior since 2025 · Diletta Solutions
Platform	Flutter, iOS and Android · web panel
Tools	Figma, Flutter, Git
Scope	3 surfaces, and I carry all three
Partner live	TicTac, a store-offers feed by Directo, a retail technology company
Period	November 2021 to today

01 Summary

Problem. Inside the partner's app, sign-up sent people off to find, download and open our app. A lot of them stopped right there. The ones who got in met a brand they didn't recognize.

Role and team. 3 surfaces, and I carry all three. Research, flows, screens and the handover to engineering are mine. The code belongs to Diletta's engineering. The partner's brand and app belong to Directo.

The decision. The partner's brand comes in through reserved places on the screen, and never on top of our colors.

Result. +34% sign-up completion inside the partner's app. The gain comes from taking installation out of the path. Before, people had to find our app in the store, download it and open it. Now the embedded flow has six screens and starts with an SMS.

Status. Live on all three surfaces. Period: November 2021 to today.

02 Context

People buying identity protection arrive suspicious. Many were already defrauded.

That changes the design. In a banking app the enemy is friction. Here it is doubt: anything that looks like a scam costs a conversion, because the user has already seen scams in that same visual language.

03 Constraint

The language this product is written in is the Diletta design system. The partner where the embedded version is live is TicTac, by Directo.

Another company's brand inside our product. In embedded mode, part of the screen belongs to the partner and part to us. That is a composition rule, and it does not fit in a color configuration file.

Sensitive personal data. Consent and identity verification follow the law, and that is where I don't improvise.

The partner decides when it updates. Their app receives our system by numbered version. A version that breaks a screen just doesn't get adopted.

04 The problem in numbers

Sign-up was losing people at three points.

Installation. On the old path, someone coming from the partner's app had to leave it, find our app in the store, download it and open it. Installation is the most expensive step in any mobile funnel.
The brand. Inside the partner, our brand showed up loose, each screen done a different way.
The demo. The standalone app served real users and the investor demo at the same time. Features showed up with no action behind them.

For background: in Brazil, a fraud is committed every 16 seconds, and the common scam imitates government and credit bureau screens. Our screen has to look verifiable. Source: Brazilian Forum on Public Security, 2024.

05 Decisions

D1 · The partner's brand comes in through a reserved place

The partner's identity comes in through colors with their own role and a fixed position in the top bar. It never overwrites our colors.

Why: overwriting opens the door for every new partner to ask for an exception. With a named role, the partner fills in what is theirs and can't reach the rest. The measurements of that composition are written in pixels, in a file.

What I gave up: letting the partner paint the whole screen in their brand. The screen feels less "theirs", and in exchange no partner can break ours.

Proof in the field: it is live inside TicTac, by Directo, and the same product still sits in the store as its own app.

SMS invite — Flow6 screens, scroll →The six screens of the entry through the partner's app. The customer gets an SMS, creates the account and leaves with biometrics on, without opening the app store.

Welcome — Flow6 screens, scroll →The six screens of the entry through the partner's app. The customer gets an SMS, creates the account and leaves with biometrics on, without opening the app store.

Checkout · order summary — FlowPayment inside the partner's store, from summary to approved. Their brand sits on the order, ours on the payment method. It is the top bar rule applied to another screen.

Checkout · approved — FlowPayment inside the partner's store, from summary to approved. Their brand sits on the order, ours on the payment method. It is the top bar rule applied to another screen.

D2 · The screen lives in a description that Figma and the app both read

Each screen is described in a format that the design and the program both read. One program builds every screen from that description. Editing a screen became editing the description.

Why: with two sources of truth, Figma and the app drift apart within a week. After that nobody knows which one is right.

What I gave up: writing a one-off screen however I felt like it. In exchange, I can measure and compare.

D3 · Each piece declares its own options

There are 88 screen pieces with their options, possible values and default written in one place. That is why a screen can be built without programming, and coverage can be checked by a program.

What I learned by getting it wrong: only the options a piece always renders can receive real data. The ones that show up only under certain conditions take the data and show nothing, with no error. I found that by accident, and it became a written rule.

D4 · A program checks all 22 flows

The program walks the product's 22 flows and returns a number. It can't see that a screen is ugly. It can see that a screen is missing, and that is the error that slips through most.

D5 · The passkey works across the whole domain

Someone registers a passkey in our product and it starts working in the other apps on the same domain, with no password typed. The partner's app joins that list by declaring our domain in its own associated domains file.

The flow order came out of that. First I ask whether the person will use more than one device, then I offer the passkey and biometrics, and the password comes last.

Why: biometrics unlocks the device, but it stays stuck there and does not carry from one app to another.

Limit: it only works inside the same domain. Two different password managers do not share the passkey, and switching phones only carries it over inside the same ecosystem. That is written down.

Back, without typing again — Coming back and being refused. In the first the profile is already saved and entry is one tap. In the second the credential did not pass. Both fields turn red and the warning drops in at the top of the screen, asking the person to check and try again.

Credential refused — Coming back and being refused. In the first the profile is already saved and entry is one tap. In the second the credential did not pass. Both fields turn red and the warning drops in at the top of the screen, asking the person to check and try again.

D6 · The brand on the login screen came from research

"Sign in with Google" has the name to ask for trust on someone else's screen. We don't have that yet. The business wanted to stay with the client's brand only until there was scale. Instead of arguing taste, I pulled the minimum standard for brand presence in login flows and brought it to the table, along with a point nobody had raised: the data protection law asks that an intermediated login be clear to the person signing in.

The proposal that came out: one line of "authentication by CPF Seguro" under the partner's logo, in their colors. One line of text handles transparency and recognition.

06 Craft

Operator overview972×526The third surface, the one almost nobody shows in a portfolio. The operator sees the standalone app's sign-up funnel broken down by stage, with the drop between each step. This is where support works from when an alert comes in wrong.

A customer's account962×778The same person as the operator sees them. The CPF Seguro tab carries "Pause CPF" and the two lists of who manages whose ID, with pending invitations and unanswered requests.

A fast check in 16 seconds, a full one in 2 minutes, and image tests that compare each screen with the approved version.
During the migration to the new system, I kept 200 name aliases so no old call in the app would break.

07 Result

+34% sign-up completion inside the partner's app. The number comes from taking installation out of the path. Before, the person left the partner, found our app in the store, downloaded it and opened it. Now the embedded flow has six screens, starts with an SMS, and the person never leaves the partner's app.

Request the account — Flow5 screens, scroll →The old path, as it was in Figma. Without our app, the person left the partner, landed in the store, downloaded, opened it and still had to log in. That is the step the six screens removed.

Redirecting — Flow5 screens, scroll →The old path, as it was in Figma. Without our app, the person left the partner, landed in the store, downloaded, opened it and still had to log in. That is the step the six screens removed.

Three surfaces live on one system. The system reaches the app by numbered version, with a record of what changes in each one. When that record was created, it showed 176 versions published since the last one the app had adopted, without a single line about what changed.

Two products on one skeleton. I split the app for real users from the investor demo. The server decides what shows up in each environment.

The process. Requests came in loose, with no written definition. I proposed an internal product committee, twice a week, to record each screen's objective and keep the decision history. The proposal was accepted. It isn't design, and it is what changed my work there the most.

08 What I would do differently

An icon was disappearing silently, and it took me a while to find it. When the system is installed as a dependency, the image files move, and the program that loads images returned empty instead of an error. The screen looked right, just without the icon. It took ten image tests before anyone noticed.

In a product that sells trust, the user doesn't see an error, they see carelessness. Today I would make the image lookup fail loudly from day one.

Next case

Diletta design system