On the visuals in this page. This is production banking software. No source code, internal design file, or screen containing customer data is shown. What is illustrated below is either public material published by BBVA México on its own website, or redacted captures of the flow as any customer sees it in the public app, with personal data removed. Everything described here about the product is either publicly documented by BBVA or general enough not to disclose anything internal.
What this is
BBVA México's payroll customers, people whose salary lands in a nómina account, mostly
hold a level 2 (N2) account. It was opened years ago, often by their employer's HR
department, on the minimum identity file the regulator allows. That file caps what the
account can receive.
This project is the flow that lets those customers lift the cap themselves, from the phone, in one sitting or across several: a modular document-collection journey that takes an account from N2 to N4, the fully documented level with no deposit ceiling.
Two of us owned the frontend end to end: UX/UI sessions with design and business, implementation, API integration, unit and E2E tests, analytics tagging against the business tagging spec, and accessibility review.
I built the original flow while at Sngular, the consultancy that placed me with BBVA México for the full engagement; the 2024 rebuild of the address module came later, after the client took me on directly. Same product, two employers, and worth stating plainly because it is the kind of detail an interviewer will cross-check against LinkedIn.
Why the flow exists: account levels are a regulation, not a product tier
Mexican banks classify every retail account into one of four levels, a scheme set out in Banco de México's Circular 14/2011 and the CNBV's general provisions under article 115 of the Ley de Instituciones de Crédito, which trade identity requirements against transactional risk. The less the bank knows about you, the less money your account is allowed to receive. BBVA publishes the resulting ladder on its own financial-education site:
- N1: name and date of birth. Ceiling: 750 UDIs a month, about MXN $6,083.
- N2: name, date of birth, official ID, address details. Ceiling: 3,000 UDIs, about MXN $24,333.
- N3: the above plus proof of address, tax record, phone and email. Ceiling: 10,000 UDIs, about MXN $81,112.
- N4: the same file as N3, fully verified. No deposit ceiling.
Limits are denominated in UDIs, an inflation-indexed unit, so the peso equivalences drift daily; the figures above are BBVA's own published ones, from Tipos de cuentas bancarias y sus características principales.
The consequence for a payroll customer is concrete. An N2 ceiling of roughly MXN $24,000 a month is fine until it isn't: a bonus, an aguinaldo, a settlement, a second job, a transfer from a relative abroad. When the deposit exceeds the ceiling it does not silently succeed; it is rejected. BBVA's own guidance is explicit that an N2 customer will receive a notification prompting them to move up to N4 and unlimited monthly deposits, triggered by their transaction volume: "si tienes una cuenta N2 básica podrás recibir una notificación para ascender a una cuenta N4 y poder disfrutar de depósitos mensuales ilimitados".
That notification needs somewhere to land. Before this flow existed, the answer was a branch visit with a physical ID, a utility bill no older than three months, CURP and RFC in hand. The product question was whether the same file could be assembled remotely, to the same evidentiary standard, by someone standing in their kitchen with a phone.
The scale that shapes the constraints
None of the public numbers below are mine to claim as project outcomes; they are the environment the flow shipped into, and they explain why the engineering decisions look the way they do:
- BBVA México closed 2024 with 32.4 million customers, of whom 24.7 million operate through mobile, 76.2% of the base, growing 11.2% year over year. 70% of the bank's 4,192 million financial transactions that year happened in digital channels (BBVA México, 2024 results).
- BBVA disperses payroll for more than 100,000 client companies, reaching over 10 million employees or beneficiaries a month (BBVA México, real-time payroll dispersal).
- Nationally, INEGI and the CNBV's ENIF 2024 found 63.0% of adults aged 18–70 hold a formal savings account, and among those, a payroll or pension account is the most common one, at 36.2%. Financial inclusion among the economically active population is 80.9% against 62.7% for the non-active: for a very large number of Mexicans, the payroll account is the relationship with the financial system.
Two things follow. First, the addressable population is enormous and overwhelmingly mobile, so a flow with a 5% drop-off at any step is losing people by the hundred thousand. Second, this is not an audience self-selected for digital fluency; the account arrived with the job. The flow has to work for someone who has never intentionally used a banking app before.
The five modules
The regulator does not ask for "documents". It asks for five distinct things, each with its own legal basis, its own failure modes, and its own definition of done. That is why the flow is five modules and not one wizard: a user can finish identity on the bus and address at home, and each module is independently shippable, testable and fixable, which matters in a bank, where every change carries its own review chain.
The steps below are the ones BBVA documents publicly for an N2→N4 upgrade in the app.
1. Official ID (INE)
Front, back, and a selfie. The INE credential is the identity anchor of the Mexican financial system; the capture has to be good enough for downstream verification, which means the UI is doing real work before anything is uploaded: framing guidance, glare and blur feedback, retake affordances, and a review step where the customer confirms the image is legible before it leaves the device.
2. Proof of address
Address data entered as structured fields, plus a photograph of a supporting document. BBVA publicly accepts a utility bill (electricity, water), a bank statement, or the INE itself, dated within the last three months. This module is the one that was later rebuilt from scratch; see Two MVPs below.
3. Tax residency (FATCA / CRS)
The customer declares whether they have tax obligations only in Mexico, or in Mexico and elsewhere. This is not BBVA's curiosity: since the 2012 intergovernmental agreement between the SHCP and the US Treasury implementing FATCA, and under the OECD's Common Reporting Standard, Mexican financial institutions must identify, classify and report accounts held by customers with tax obligations abroad, via the SAT; an obligation the whole sector documents in near-identical terms (Santander México, FATCA/CRS FAQ).
The interesting UI problem is that the vast majority of users answer "Mexico only" in one tap, while a small minority open a branching form that needs a foreign tax ID and a country. Optimising for the common path without making the rare path feel like an error is most of the design work.
4. KYC questionnaire
A four-section declaration (general information, account information, financial operations, and use of credit) that establishes the customer's expected transactional profile. This is the module where the regulation is least visible to the user and most consequential to the bank: the answers become the baseline against which future activity is judged.
5. Beneficiary
Who inherits the balance. Sensitive in a way the other modules are not, being the only step that asks the customer to think about their own death, and the only one that collects personal data about a third party, which brings its own obligations under Mexico's data protection law.
Architecture
Modules, not steps. Each of the five is self-contained: its own state, its own API contracts, its own error handling. An orchestration layer tracks which are complete and returns the customer to where they stopped. Nothing about the regulation demands one sitting, so nothing about the implementation assumes one. The payoff was structural rather than theoretical: it is what made the 2024 rebuild of a single module possible without regression risk to the other four.
An internal Web Components framework, Lit, TypeScript. The bank has its own in-house framework built on Lit, with its own component catalogue, routing and state conventions. It is not a framework you choose; it is the one you are given. In practice that meant no npm packages, no external component library, no escape hatch. The constraint turned out to be a useful forcing function: with no library to reach for, the answer to most problems was a smaller amount of plainer code, which is also the code that is easiest to audit.
The API is the contract. The backend endpoints predated the project. We were consumers, not designers, adapting to data shapes we did not control, handling partial responses, validation states that did not map cleanly onto a screen, and error codes that did not map cleanly onto a sentence a customer could act on. Every one of those had to become a specific, recoverable UI state rather than a generic failure.
Technical notes
Analytics tagging was a first-class requirement, not an afterthought. Every module entry and exit, every user action, and every API result had to be instrumented against a tagging specification owned by a separate business team. In a flow whose entire purpose is completion, the tagging is the product feedback loop; it is the only way anyone finds out which of the five modules is losing people. Getting it right meant treating tag emission as behaviour under test, not as a side effect sprinkled into event handlers.
Accessibility, in a domain where it is measured. In 2023 the CNBV, with GIZ, published Inclusión financiera de las personas con discapacidad: retos y recomendaciones, which assessed Mexican banks' websites and mobile apps against WCAG 2.1 and issued recommendations grounded in disability as a protected category. Accessibility here is not a lint rule you satisfy: a compliance flow that a screen-reader user cannot complete leaves that person capped at MXN $24,000 a month.
Document capture is where the web platform gets thin. Everything else in the flow is forms. The ID and proof-of-address modules need the camera, image handling, and a quality judgment made on-device, inside a Web Components framework with a fixed component catalogue. It is the part of the flow with the least support from the stack and the most impact on whether a customer succeeds.
Two MVPs
2023, the full modular flow. The first production release covered all five modules. The priority was getting the happy path into customers' hands and validating that the modular architecture held. The address module worked, but it was built on the previous UI pattern.
2024, the address module rebuilt. BBVA introduced a new UX design language and updated internal tooling. The second MVP was scoped to exactly one module: proof of address, rebuilt from scratch in the new system while keeping the same API contracts, so nothing changed from the perspective of the other four modules or the customer moving between them.
That is the clearest evidence the architecture was right. A year later, one fifth of the product could be replaced in isolation.
Outcome
The flow shipped to production and reached BBVA's payroll customer base, a base that, per the bank's public reporting, counts in the tens of millions, most of it mobile. Its function is unglamorous and load-bearing: it is the difference between a customer clearing their deposit ceiling from the sofa and a customer taking a morning off work to stand in a branch.
For me it was the project where I moved from executing tickets to owning a product surface: sitting in the design and business sessions, arguing the tradeoffs, and being accountable for the whole delivery rather than a slice of it.
Sources
Every figure and regulatory claim on this page comes from public material. Nothing here is drawn from internal BBVA documentation.
- Banco de México, Circular 14/2011, the account-level scheme.
- CNBV, Disposiciones de carácter general aplicables a las instituciones de crédito, the identity-file requirements behind article 115 of the LIC.
- BBVA México, Tipos de cuentas bancarias y sus características principales: the N1–N4 ladder, the UDI ceilings and their peso equivalences, and the N2→N4 upgrade notification.
- BBVA México, 2024 results: customer base, mobile share, digital transaction volume.
- BBVA México, real-time payroll dispersal: client companies and employees paid monthly.
- INEGI and CNBV, Encuesta Nacional de Inclusión Financiera 2024: account ownership, and the share of formal savings accounts that are payroll or pension accounts.
- CNBV and GIZ, Inclusión financiera de las personas con discapacidad: retos y recomendaciones (2023): WCAG 2.1 assessment of Mexican banks' web and mobile channels.
- Santander México, FATCA/CRS FAQ: the sector-wide reporting obligation and the tax-residency self-declaration.