Demystifying Screenless Exchange

In a recent whitepaper on data access methodologies, Plaid introduced its Screenless Exchange method of authenticating access to one’s bank account.

This novel protocol separates design from security. As a result, it minimizes tradeoffs to enable the best of both design and security practices when a user connects a bank account to a third-party app.

To understand Screenless Exchange, it’s important to first understand how authentication and tokenization affect consumer access to data.

Let’s unpack these concepts, starting with the basics.

Laying the groundwork

Simply stated, Screenless Exchange is a type of tokenized authentication.

Authentication generally refers to methods that let a user grant permission to a third party to access personal data that resides elsewhere. For example, when logging in to Airbnb, a consumer might permission access to her Facebook account, allowing Airbnb to automatically pull in her profile photo and current city. Authenticating in this way also serves as partial verification of an identity, reducing the potential for fraud.

In financial services, authentication often refers to the specific flow by which a user grants access to bank data. In the early days of digital authentication, a user would provide bank login credentials directly to the party seeking permission. In other words, an application such as Mint would receive a user’s banking credentials. And while it was one thing for Mint (later bought by Intuit) to store credentials, as the digital space grew, many new, smaller developers began to collect credentials as well. The spread of credentials to small developers—not all whom had significant security resources or experience—naturally raised concerns. But authentication methods have evolved to mitigate this problem.

Modern versions of authentication adopt tokenization. Perhaps best known for its role in the credit card industry, tokenization is the substitution of a non-sensitive data element for a sensitive element. For instance, a bank (or trusted intermediary sitting between a bank and third-party app) might exchange login credentials for a unique “token”—typically a random character string—that is provided to the app. The app then uses the token to access that specific customer’s data, eliminating the need for the app to store sensitive information like credentials.

Only the “token provider” (e.g., bank or trusted intermediary) can access the token “vault” mapping the token to the sensitive data element. The token is therefore useless if compromised.

Tokenization is often conflated with encryption—which achieves a similar objective, but is distinct. Encryption uses an algorithm (sometimes called a “key”) to convert a sensitive data element to a non-sensitive one, rather than substituting a randomly generated token. Thus, an encrypted data element can theoretically be maliciously decrypted if the key is compromised.

Modern data access concepts

This all may sound good in theory—but begs the question of what tokenized authentication looks like in practice.

In digital financial services, Plaid presents one leading solution. In this flow, an app connects with a bank via a trusted third-party intermediary (in this case, Plaid). The user inputs his or her credentials, which are passed directly to the bank via the trusted intermediary. The application never sees or stores user credentials, significantly reducing the potential for credential compromise and fraud.

Across all industries (not just in financial services), the best-known implementation of tokenized authentication today is called OAuth. OAuth is an authentication mechanism that relies on a series of “handshakes” that exchange information between an app and financial institution servers in order to permission data access. The app receives a token, rather than credentials, for data access. Widely used by technology companies—including Twitter, Facebook, and PayPal—OAuth has more recently attracted attention from traditional financial institutions.

OAuth is generally a sound authentication method. But its flow can be cumbersome for users. OAuth typically relies on a redirect from an app (Airbnb, in the earlier example) to the platform hosting data (Facebook). This can be accomplished by an app switch (on mobile) or a browser redirect (on mobile or desktop).

Both app switches and redirects result in subpar user experiences. Users may lose patience with a clunky redirect, not have the latest version of an app installed, or even be turned off by poor design. This leads many users to abandon the process, reducing conversion.

Enter Screenless Exchange

This is where Screenless Exchange comes in. Screenless Exchange combines the security advantages of OAuth—such as tokenization—with the design elements offered by solutions like Plaid. Specifically, Screenless Exchange is different because it allows a user to permission access to personal financial data without ever leaving the original app. The native experience eliminates the barriers and clunkiness of redirect-based OAuth, increasing user conversion. And the financial institution can customize the look and feel of permissioning access for its customers.

In Screenless Exchange, users directly enter their credentials in a Plaid iframe—essentially, an embedded Plaid experience that sits within an app. The credentials are immediately encrypted (or “hashed,” which is a method of disguising sensitive data that cannot be reverse engineered, not unlike tokenization) and sent directly to the data-hosting financial institution. Credentials are not sent or stored anywhere else—a fact that can be easily verified through a routine server audit. The trusted intermediary instead receives a unique token to permission data access on behalf of the app, similar to the traditional OAuth flow.

Adoption of Screenless Exchange

Implementing Screenless Exchange admittedly requires some tech lift from financial institutions—though less so than OAuth. And for financial institutions that want to employ end-to-end tokenization, Screenless Exchange may be the best possible solution that exists today. It arguably combines the best in security and design for a safe, streamlined user experience.