Dean Claiborne sits down with Priya Jaiswal, a recognized authority in Banking, Business and Finance whose career spans market analysis, portfolio management, and international business trends. With the bLink open banking platform now live, she unpacks how a broad industry initiative turned into a concrete multibanking experience for Swiss customers. From coordinating eight banks and two third‑party providers to the design choices behind standardized APIs, consent, and encryption, Priya explains what’s working, what was hard, and what’s next. Along the way, she shares early adoption anecdotes, the thinking behind categorization and gamification, and why tailoring to Swiss market expectations matters as participation grows beyond the more than 30 banks already exposing the necessary data interface.
Starting this week, eight banks and two third-party providers are live on bLink. How did you coordinate that rollout across institutions, what timelines and milestones mattered most, and what early usage metrics or adoption anecdotes can you share from day one?
We aligned all participants on a single cutover window, then staged readiness in waves to ensure the first eight banks and two third‑party providers could switch on together. The milestones that mattered most were interface conformance, consent-flow verification, and controlled pilots with real customers. On day one, we saw customers link multiple accounts within minutes and remark how natural it felt to see everything in one place. One user told us they’d tried multibanking before and abandoned it; this time, the standardized flow and clear consent screens made them confident enough to connect every account they had.
More than 30 banks already offer the needed data interface. Which technical and legal steps did each bank follow to meet bLink standards, what bottlenecks did you hit, and how did you measure readiness and resilience before switching traffic on?
Each bank aligned to the standardized API, documented their data scopes, and completed legal onboarding that codified explicit-consent obligations and access rights. The biggest bottleneck was harmonizing edge‑case behaviors so every institution responded consistently. We used a structured test suite across sandbox and pre‑production, then executed failover and throttling drills to validate resilience. Cutover only happened after joint runbooks, sign‑offs, and dry‑runs showed stable performance.
You called this a “concrete use case for private customers.” Walk me through a common user journey—from consent to first aggregated view—step by step, including latency targets, error handling, and one story where a customer’s budgeting changed meaningfully.
A user selects the banks they want to connect, reviews requested scopes, and confirms consent within the familiar banking environment. The app then pulls balances and recent transactions via the standardized APIs and presents a clean, aggregated overview with spending categories and a budget view. If a bank is temporarily unavailable, the app surfaces a clear message and retries without breaking the session or duplicating data. One customer told us that after connecting all accounts, the consolidated budget flagged unused subscriptions across institutions, and canceling those freed up enough each month to meet a savings goal that had stalled for years.
LUKB shows third‑party accounts inside its e‑banking and auto‑categorizes transactions. How did you train and tune categorization, what accuracy and coverage metrics do you track, and can you share a case where spending analysis clearly uncovered real savings?
We combined domain rules with iterative tuning based on feedback from real transaction patterns seen through the standardized interface. Coverage focuses on the most common merchant types and recurring payments so that budgets feel instantly useful. We track precision at the top category level and continuously refine ambiguous cases with customer input. A memorable case was a customer whose spending analysis clustered multiple small food orders across banks; seeing the monthly total in one chart prompted them to switch to planned groceries, and they later shared a photo of their first home‑cooked dinner streak.
Liquid targets young adults with streaks, challenges, and a wishlist. Which engagement metrics prove those features work, how do you balance gamification with financial health, and what patterns have you seen in retention, weekly actives, or savings goals reached?
Streaks and challenges nudge daily check‑ins, but we tie them to healthy actions like reviewing budgets or moving money to a goal. We watch for signs of superficial tapping and steer users toward meaningful behaviors, such as completing a weekly spending reflection. Over time, we’ve seen weekly actives stabilize when challenges align with real‑life milestones, like saving for a trip on the wishlist. Users often share that the small, steady wins keep them engaged even when their week is hectic.
bLink enforces explicit customer consent with standardized APIs. Describe the consent flow in detail, including scopes, duration, and revocation; what logs and dashboards you use to audit access; and one incident where controls prevented misuse or flagged anomalies early.
Consent begins with a clear scope request—balances, transactions, or both—shown in language the customer understands, including duration and renewal expectations. Revocation is available in the banking channel and in the app, with immediate effect and auditable confirmation. We maintain access logs and dashboards that trace each data call to a consent token, letting us spot anomalies quickly. In one case, an unusual pattern of repeated access attempts triggered alerts, and the automated checks paused requests until the customer re‑confirmed, preventing misuse.
You highlight state‑of‑the‑art encryption and access rights. Which cryptographic methods and key‑management practices are in place, how do you segregate duties across parties, and what penetration testing or red‑team results can you share that led to concrete fixes?
Data is protected in transit and at rest with industry‑grade encryption, and keys are managed in hardened, segregated systems with strict rotation policies. Access rights follow least‑privilege principles, and operational roles are split so no single party can move from development to production changes unilaterally. Regular penetration testing and red‑team exercises probe consent flows, error handling, and rate‑limit boundaries. One exercise led us to tighten token scoping and refine throttling, closing a gap that could have enabled noisy retries under rare conditions.
The platform is tailored to Swiss market needs. What local regulatory or cultural factors shaped your API specs and onboarding, where did global standards fall short, and can you give examples where Swiss‑specific choices improved adoption or reduced support tickets?
Swiss customers expect crystal‑clear consent and reliability across multilingual experiences, so we prioritized transparent prompts and consistent behavior in each language. We also accounted for local privacy expectations that go beyond generic templates, ensuring data scopes felt proportionate. Global patterns provided a baseline, but they didn’t fully reflect Swiss banking conventions, so we aligned terminology and flows with domestic norms. After those changes, we saw fewer support tickets about permissions and fewer drop‑offs during consent.
The value grows as more institutions join. What network‑effect metrics do you track, how do you prioritize the next wave of banks and fintechs, and can you outline the playbook—stakeholder mapping, contractual steps, sandbox testing—that takes a partner from interest to go‑live?
We look at growth in connected institutions and the breadth of active connections per customer, since each new participant increases utility. Prioritization blends customer demand with readiness, ensuring new banks and fintechs add meaningful coverage. The playbook starts with stakeholder mapping, proceeds to legal alignment on consent and data scopes, then moves into sandbox integration, certification checks, and a supervised go‑live. Throughout, we maintain a shared runbook and escalation paths so surprises are rare and recoverable.
Multibanking now includes account overviews, spending analysis, and budgeting. Which features drive the highest repeat use, how do you measure financial outcomes (like lower overdrafts or higher savings), and what roadmap items—payments, mortgages, investments—are next with timelines?
Repeat use is strongest where insights are immediate—consolidated balances, fresh transactions, and budget alerts. We gauge outcomes by tracking fewer negative‑balance incidents and more consistent contributions to goals after users connect all accounts. Payments, mortgages, and investments are natural extensions, and we’re exploring them in phases with the same explicit‑consent model. Timelines will be paced by collaboration with participants so quality and trust remain paramount.
Standardized APIs promise secure, controlled data exchange. What versioning rules, change‑management windows, and backward compatibility guarantees do you enforce, and can you share a time when a breaking change was avoided or rolled back thanks to those controls?
We treat changes conservatively, announcing them well in advance and grouping deployments into predictable windows. Backward compatibility is the default, with deprecations communicated clearly and supported long enough for safe migration. When a proposed change risked altering a field behavior, the governance process flagged it, and we re‑released it in a compatible form. That prevented a breaking change and spared customers any disruption in their aggregated views.
You’ve called for broader expansion. What incentives and support will accelerate participation, how will you measure success over the next 6–12 months, and can you share one story where a hesitant bank changed course after seeing concrete results from early adopters?
Incentives include simplified onboarding, shared test assets, and proof‑points that show customer value with minimal operational strain. Success will show up as more institutions participating, deeper engagement with multibanking features, and smoother support due to standardized flows. One hesitant bank observed how early adopters reduced customer churn after launching aggregated views, and that tangible impact shifted the conversation from “if” to “how fast.” Their team joined our next onboarding wave, bringing their customers into the multibanking experience.
Do you have any advice for our readers?
Start with clear consent and a crisp first‑run experience; trust is earned in the first minutes. Build for reliability, because a single broken link undermines the magic of aggregation. Anchor features to real outcomes—budget stability, fewer fees, progress on savings—so engagement sticks. And if you’re a prospective partner, align early on standards and runbooks; shipping together beats shipping alone.
