Bank Link
In early 2023, The company I was working for launched its Aggregation product for UpBank, starting with 3 banks and expanding to 8 throughout the year (Scotiabank, BBVA, Falabella, Popular, Bogotá, Occidente, Serfinanza, and Caja Social). By January 2024, all 8 integrations were live.
Context
While GoBank had developed its own custom front, new fintech clients requested that our product provide a ready-to-use front-end to manage consent and authentication. This request led to the creation of Bank Link (internally called “Redirect”), a neutral front that any client could integrate.
GOAL
Design and build a front-end that:
Clearly informed users about the data being shared, purpose of use, and validity of consent.
Resolved ambiguity between what the client wanted (generic text) and what regulation (Circular 004, Colombia) required (specificity and clarity).
Created trust and security for users, while remaining neutral so it could fit within any client’s brand.
At the same time, the back-end needed traceability to track each consent’s status:
Pending → consent created but not completed.
Authorized → user completed and approved the flow.
Rejected → user did not authorize the connection.
SOLUTION
I designed and prototyped the complete front-end flow, including:
Welcome screen – explaining the 3 steps: give consent, select bank, connect.
Consent screen – detailing data shared, purpose, usage, and validity, plus links to our product T&Cs and privacy policy.
Bank selection – list of supported institutions.
Credential entry – login fields for scraping, OTP validation, redirects, or API-based flows.
Disconnect flows – including API's special case, where users were redirected to bank support to revoke access.
I also designed demo screens (in prototype) simulating a client app to showcase different flows:
BBVA → scraping.
Bancolombia → API with redirect.
Nequi → API with in-app approval.
Falabella → disconnect flow.
VISA → card connection.
The design used a neutral, sober style to convey security while staying adaptable for any client. A future idea (not implemented) was to allow clients to customize colors, typography, and button styles.
TOOLS
My role & scope
Designed and prototyped the entire front-end flow in Figma.
Defined how to communicate legal and regulatory requirements in a clear way for users.
Advocated for our company to own the responsibility of presenting data usage information (as the intermediary, not the end client).
Collaborated with frontend developer to hand off designs and ensure feasibility.
Iterated the design after feedback from clients, and regulatory updates.
Research & benchmarking
To ground the design, I studied flows from leading providers: Plaid, Tink, and Modo. These benchmarks showed best practices on how to display data usage, consent duration, and authentication steps.
To ensure a clear and consistent experience, I mapped the end-to-end flow of Bank Link. This architecture defined the key steps users would go through—from onboarding and consent, to bank selection, authentication, and returning to the client app. It also included alternative paths, such as viewing legal texts in detail or abandoning the connection, which were essential for compliance and user trust.
Wireframes & design decisions
Given the regulatory complexity and client ambiguity, the approach focused on clarity and iteration:
Define the purpose of each screen (e.g., What must the user clearly understand at this step?).
Medium-fidelity wireframes, mobile-first Built in FigJam, emphasizing flow, hierarchy, and consent communication.
Rapid validation with stakeholders Iterated with Product Head and legal/compliance feedback to refine flows, copy, and data usage texts.
Adapting to multiple connection types Designed flexible patterns to cover scraping logins, API redirects, OTP validation, and disconnect flows.
Scaling to desktop Once mobile clarity was achieved, layouts and components were adapted for desktop while preserving consistency.
Iteration & feedback
The first version of the wireframes provided the basic structure of the flow, but client and regulatory feedback highlighted the need for more clarity, trust, and compliance.
In the iterated version, I introduced several key improvements:
Institutional clarity: added the logos of the institutions involved in the connection to make the process more transparent.
Improved copywriting: refined messages to increase user trust and understanding.
Account disconnection option: introduced the ability to disconnect accounts at any time—legally required and reassuring for users.
Data transparency: detailed what data would be shared and how it would be used.
Legal alignment: included terms & conditions and privacy policy, replacing the checkbox with a “Accept and Continue” button, reducing friction while staying compliant.
Brand clarity: added a “What is” section to explain the company’s intermediary role in facilitating secure connections.
These changes made the flow clearer, more trustworthy, and compliant with local regulations while reducing friction for the end user.
Final design
Delivered a neutral, adaptable consent flow that could be reused by multiple clients.
Improved compliance by making legal texts clear and specific.
Enabled product to commercialize aggregation with clients who lacked front-end development capacity.
Established traceability in the back-end with consent_status for pending, authorized, and rejected flows.
In the prototype you can test different flows:
Success API (with redirection) → Bancolombia
Success API (with in-app approval) → Nequi
Success Scraping → BBVA
Connection error → Falabella
Expired session → Scotiabank
Other cases:
Disconnection → at the beginning, by tapping “Ver cuentas conectadas”.
Abandoned flow → by tapping the “X” in the upper corner.
What did I learn from this project?
Regulation shapes design more than expected. Circular 004 forced me to think not just about usability, but also about compliance. Clear, specific language wasn’t optional—it was a legal requirement.
Ambiguity is part of the process. Clients wanted generic text to avoid responsibility, while regulators pushed for specificity. Navigating that tension taught me how to defend user clarity without breaking business constraints.
Neutral design can be powerful. By keeping the interface sober and adaptable, the solution became reusable for different clients —a real example of design as a business enabler.
Traceability is as important as UX. Designing a smooth front-end wasn’t enough. Ensuring each consent had a status (pending, authorized, rejected) made the product reliable and auditable.
Benchmarks accelerate clarity. Studying Plaid, Tink, and TrueLayer gave me a concrete base of best practices to adapt to LATAM’s regulatory and cultural context.
What would I have done differently?
Document legal texts and design decisions from day one to speed up alignment with clients and regulators.
Prototype earlier variants for consent screens to validate language faster.
Push further on customization options (colors, typography, components) so clients could adapt without extra dev cycles.
What did I take for the future?
Confidence in bridging design, regulation, and business needs.
Tools to design neutral, reusable solutions that scale across clients.
Experience in turning regulatory requirements into clear user-facing flows.
A stronger sense of responsibility as a designer when handling sensitive data and user trust.