Open APIs are the focus of attention now in corporate IT. Recently the U.S. bank Capital One launched three new open APIs in a move that signals a shift towards open banking platforms. An Open API — often referred to as a Public API — is a publicly available application programming interface (API) that provides developers with programmatic access to a proprietary software application. Capital One is one of the first banks to open up their APIs, allowing developers to utilize these APIs to potentially create a new ecosystem of third-party applications. In reviewing these APIs from a UX design perspective, I feel that it should be a goal in API planning to enable the design and delivery of a good consumer user experience given the API constraints.
As an experienced UX practitioner who focuses on UX architecture and interaction design, I’ve worked with many clients spanning large corporations, startups and government organizations. Crafting an API should take into account the means by which end users will access and interact with the data, enabling an easy to initiate and seamless task flow for the target user. From my analysis, it appears that an Open API does not necessarily lead to a good user experience and I feel that end user “ease of use” should be a goal and one of the attributes considered during API planning.
From a UX perspective, I analyzed the first API, SwiftID, a two-factor authentication service because improving authentication experiences — in particular multichannel UX — is top of mind for me as I have been working recently on authentication UX architecture. The other two APIs include an API for accessing customer rewards information (Rewards API) and an API to enable consumers to submit their financial profile and receive pre-qualification for specific Capital One services (e.g credit cards).
Crafting an API should take into account the means by which end users will access and interact with the data, enabling an easy to initiate and seamless task flow for the target user.
Two issues for me stand out with the SwiftID API regarding their impact on the end-user experience:
(1) the degree of the seamlessness of the authentication flow
(2) via third-party authentication — access to an overly “personal” view of the user’s identity and personal financial profile.
What kind of flow does the authentication API enable for the consumer?
Two-factor authentication (often using the consumer’s mobile phone) is the current best practice for access to consumer banking applications. Signing in to my Bank of America mobile app means I have to request a numerical code using SafePass(R) during authentication in order to verify my identity. I receive the numerical code via text message, which I then must enter into the SafePass input field in order to complete authentication. The state of being “authenticated” means that the app has identified me as the person who has the credentials (username and password) as well as the specific phone and the numerical code that SafePass generated. In the context of a banking app, the state of authentication also means that my personal financial information is accessible, which I’ll explain later on.
The state of being “authenticated” means that the app has identified me as the person who has the credentials (username and password). It may not actually be “me” — it might be someone who has my credentials and phone.
A good UX question to ponder is: does the SwiftID API enable an authentication experience that is at least as good as two-factor authentication? When designing a flow using the SwiftID API to enable an authentication experience for a consumer (in this case, using a mobile-first approach) the result is an experience that is not so good for the user: it’s not seamless and it requires shifts in context (screen transitions to different applications). For an example of the flow enabled by the API for a sample third-party app “App A”, see Figure 1.
There are some requirements for the consumer before the SwiftID API can be used with third-party apps. The consumer must (A) be a Capital One customer, (B) download the Capital One Mobile app and (C) in the Settings area turn on the SwiftID service. (Note: At the moment, this service is only available for iOS.)
Steps A, B and C are a lot of work for a consumer to do before they can attempt to use the SwiftID to authenticate, and I’m not sure how the consumer would know they need to do these required steps without a lot of guidance in the UX. As Figure 1 shows, during the authentication process in Step 4 the user must switch context from the third-party app initiating the authentication request (App A) to the Capital One Mobile app — shown in Step 5. Note that as part of this step there is a stopping point on the home screen with a notification to launch the Capital One Mobile app. Consider this scenario: what if the user has iOS notifications turned off?
In Step 6 there is another transition from the home screen to the Capital One Mobile app. Now the user has made two app transitions and is about to perform a third one. Tapping Approve (Screen 6) then transitions the user back to the third-party app. For me, as compared to two-factor authentication in my Bank of America mobile app, three app transitions are too many.
This leads me to my next thought on Open APIs for banking, at least for authentication: a user experience that allows me and all of my financial data to be identified as “me”.
Access via API to an overly “personal” view of the user’s identity and personal financial profile
Conventional two-factor authentication validates that I am the person with the two factors: the credentials (username and password), and the correct phone. My identity is not associated with this authentication, only that I am the individual that registered for it. Someone who has my credentials and phone could authenticate as “me” because two-factor authentication validates only that I have the correct credentials. It does not confirm my identity.
However, authentication via a third-party app using an Open API for banking means that my banking credentials for my financial institution and all of my financial data become part of my authenticated state. See figure 2 for the flow of data during the authentication process.
Consider an example: if Facebook allows me to authenticate using my banking credentials, then all of my Facebook profile data in addition to all of my financial data is then available in that authenticated state. This aggregate view of my profile and financial info offers a much more complete, 360-degree view of me — and my complete identity. As a user experience, it delivers a complete representation of the user’s identity, one that may be too invasive for a relationship I want to have with my third party, non-financial applications.
Conclusion
Crafting an OpenAPI requires consideration for the end-user flows that will be enabled (or hindered) by the API and this should be a standard part of the process of API definition and part of the API design discussion. The perspective of UX architecture should inform the API planning to ensure a seamless end-user experience and end-to-end flows should also be considered.
Separately, the move towards open banking APIs may end up compromising the user experience and result in too much information about a banking customer being shared with a third-party app. Users may consider this as an “overly invasive user experience” which in turn could have an impact on end-user adoption of applications that utilize these APIs.
About the author
Karen Donoghue is a Principal at HumanLogic, a user experience design consultancy. She has written two business books on user experience and earned an MS at MIT.