As open banking evolves from read-only to read-write capabilities, the user experience (UX) becomes the battleground for trust, engagement, and differentiation.
While APIs and compliance frameworks enable data portability, it’s the design of the journey, from consent to transaction, that determines whether customers stay or stray.
Open Banking write access is a threshold moment. It upgrades Open Banking from a rearview mirror diagnostic to a steering mechanism that positions the payment initiator (Accredited Action Initiator AAI) ahead of the payment executor (Account Service Provider ASP) up the relationship ladder.
This power shift makes the trust architecture the make-or-break moment of the user experience (UX). With this, there are real trust friction points that need consideration in the UX.
🔐 Consent Comprehension vs. Consent Execution
Many AAIs ( Data Recipients) will excel at gathering user consent with slick interfaces, but users rarely grasp what “write access” actually entails.
Whilst the ASP (Account Service Provider) becomes the fallback risk-bearer if the AAI’s instructions are misaligned or misunderstood, it is incumbent on the initiator to provide the upfront clarity about what is going on. Behavioural UX patterns like “trust nudges” and progressive content as provided by www.moroku.com/odyssey are gaining traction, to resolve this challenge, educate and comfort users.
Part of the challenge here is authentication continuity. Transferring authentication context securely from an AAI to an ASP during a write action is fragile, especially with cross-device or cross-channel journeys. At the same time, every extra security prompt or redirect risks abandonment. With ASPs being naturally risk averse to others initiating transactions, often falling back to over-cautious fail-safes, adoption will be hampered.
Federated identity, low-friction identity token sharing and native OS-level authentication (e.g., biometric passes) continue to present the path forward to bridge the gap with less cognitive toll upon the user and security infrastructure demands for both the ASP and AAI.
⚖️ Blame Assignment in Edge Cases
When something goes wrong (e.g. duplicate payments, misrouted transfers), users don’t know who’s accountable; the AAI who initiated, or the ASP who executed. If there is liability ambiguity trust will be eroded. No one likes dealing with “not my problem” call centres.
Plainspoken audit trails, marketing by the central banks and fast, co-owned dispute resolution protocols between AAIs and ASPs are critical here.
🧠 Invisible Decisioning by AAIs
Payment initiators are increasingly embedding behavioural scoring, nudges, or spending controls, but don’t always disclose when or why these are triggered. Users can feel subtly manipulated or second-guessed by these especially when the ASP is perceived as the more “neutral” actor. Explainable AI overlays and user-adjustable settings (with ASP-mediated overrides) can really help users regain agency and trust.
The evolution from Open Banking read-only to write begins not with technology, but with transparency, traceability, and mutual accountability as core design principles. This is why we have strong UX designers in our team at MOROKU that are focussed on user success and emotional intelligence.