TokenOS is the operating system for open banking. It provides turnkey PSD2 compliance and allows third-party developers to easily and securely develop applications that include payment initiation and account information retrieval.
TokenOS provides a global open banking API that easily connects with a bank’s existing infrastructure.
At the core of TokenOS is the smart token, providing authorization to access an underlying asset. Smart tokens are programmable by defining conditions (rules) governing access to the asset.
Multiple parties connect with TokenOS
- Bank customers, merchants and third-party providers (“API callers”) access banks through the Token cloud.
- The Token cloud serves the Token open API. It acts as a router, generates smart tokens and verifies the conditions and digital signatures.
- Banks/financial institutions provide the access to their customers’ funds and account information.
Members exchange funds or information through open, secure transactions with TokenOS. End users (customers/payers), merchants, and third-party providers are all members of the Token network.
Using the Token SDK, member entities are created and linked to bank accounts.
Token members communicate through the Token cloud using the Token API. The easiest way to get started is to use one of the Token SDKs.
The Token cloud is distributed, with services hosted on geographically dispersed servers operated by Token and its partners.
The Token cloud is integrated with banks/financial institutions through a thin integration layer that allows access to a bank’s core banking services.
A smart token is an authorization to access an underlying asset. Akin to “smart contracts”, smart tokens are programmable by defining conditions that govern access to the smart token’s asset. A smart token masks its underlying asset, such as an account number. Smart tokens are immutable: neither a smart token’s asset nor its conditions can be changed after the smart token is created. Every smart token has a unique Token ID.
The diagram shows the components of a smart token.
There are two kinds of smart tokens: Transfer Tokens and Access Tokens.
Transfer tokens provide authorization to transfer assets, such as the funds in a bank account. A transfer token’s conditions make transfer tokens much more powerful than typical payment API functions.
Extending the “smart contract” concept, transfer tokens function as programmable money. For example, a merchant (payee) might ask a user (payer) to authorize a smart token to pay for an online purchase: “Allow Merchant XYZ to initiate a payment from my account at Iron Bank to pay €224 for order 79262212.”
A typical use is to enable a payment between two parties.
Transfer tokens are payment-method agnostic: the transfer token initiates the payment, but the payee determines which payment rails to use.
Transfer tokens can be single-use (redeemable only once) or multi-use (redeemable multiple times).
Access tokens provide authorization to access customer information. An access token’s conditions control what can be accessed (that is, the asset), who can access the asset, and how the asset can be accessed. For example, a user could authorize a service such as Mint to access and aggregate all her account information, or authorize a merchant to access her shipping address.
Typical applications for access tokens are to retrieve, verify, and aggregate a consumer’s financial information across multiple accounts. (Access tokens can be extended for other types of information.)
Typical access token assets are PII; account information, such as balances and transaction history; and physical addresses.
There can be only one access token for a given payer-redeemer pair, which simplifies access token management for a consumer. To revise an access token’s permissions, replace the access token with a new access token that has the updated permissions.
Access tokens are multi-use; that is, they authorize access an unlimited number of times, until they are canceled.
Smart Token Lifecycle
The smart token lifecycle is the same for transfer tokens and access tokens.
An asset owner is the party whose asset is contained in the smart token.
For transfer tokens, the asset owner is the payer. The other party in the smart token “contract” is the payee (for example, a merchant).
For access tokens, the asset owner is the grantor; the Token member who allows another Token member (the grantee, who is the other party in the smart token “contract”) to retrieve information and perform operations on behalf of the grantor. The grantee is the party who will redeem the asset.
Request. A Token member requests a smart token from another party; for example, a merchant asks a customer for a payment (which requires a transfer token) or for information such as a shipping address (which requires an access token).
Create. Any Token member can create a smart token by calling the Token API.
Endorse. The asset owner; for transfer tokens, the payer; for access tokens, the grantor; endorses the smart token by digitally signing it. For transfer tokens, after the payer endorses the smart token, the payer’s bank also does.
Redeem. After the asset owner endorses the smart token, its token ID is given to the asset redeemer. For transfer tokens, the redeemer is the payee (typically), the payer, or another member specified by the token creator. For access tokens, the redeemer is the grantee. The redemption process varies depending on the type of smart token.
Cancel. At any time during the lifecycle (not just as the last step as listed here), either party can cancel the smart token. Typically, it is the asset owner who cancels a smart token.
TokenOS provides a high level of security for all parties: users, merchants, banks/financial institutions and other organizations.
Banks can control and verify every transaction, and therefore do not need to trust cloud providers. This further increases TokenOS security.
Member’s private keys and credentials are never uploaded to the Token cloud, nor shared with any entity in Token’s network, which greatly reduces the risks and dangers of mass breaches.
SDKs enable the use of secure hardware when available, such as trusted execution environments, secure enclaves, and HSMs.
Digital signatures are used for authentication and to ensure integrity. The TokenOS supports multiple signature algorithms, including Ed25519 and ECDSA. Using digital signatures eliminates the risk and complexity of OAuth 2.0.
Smart tokens enable secure contracts between two or more parties, and prevent any other party from accessing and using them. Smart tokens are immutable, guaranteed by IDs that are hashes of their content (which includes sender, receiver, terms, limits, and so on). PII is never exposed without the consent of the asset owner, and no login credentials are ever exposed.
TLS is used in all communications.
TokenOS uses PKI (public key infrastructure) to secure communications between the Token cloud and its clients (Token members and banks/financial institutions). Public keys are stored in the Token cloud, are publicly shared, and require valid signatures to be changed. Private keys are never shared. Each Token API invocation is digitally signed by the caller using its private key(s), and the Token cloud and banks verify the API request by using the caller’s public key. The Token SDKs greatly simplify the development process by wrapping the PKI complexity in a set of simple interfaces.
TokenOS supports the SCA (strong customer authentication) requirements of PSD2, whereby transfers over a threshold amount require two-factor authentication (2FA). 2FA requires that authentication include any two of the following:
- Knowledge: Something only the Token member knows, such as a password or PIN
- Possession: Something the Token member possesses, such as a private key on a mobile device
- Inherence: Something the Token member is, such as a fingerprint or biometric characteristic
During the Token member registration process, the Token SDKs generate three keys for the Token member:
Low level key - Enables most Token SDK calls, except: endorsing high-value transfer tokens, endorsing access tokens, adding/deleting aliases (email addresses, phone numbers, …) and keys.
Standard level key - Enables low level key operations, plus endorsing high-value transfer tokens and endorsing access tokens.
Privileged level key - Enables standard level key operations, plus adding and deleting aliases and keys.
The Token cloud manages and maintains a secure directory that enables alias resolution and mapping of Member IDs to public keys. The entries in the directory are chained and cryptographically verifiable. To add or delete a key, a Token member must sign the add/delete request with their existing key.
Private keys are never uploaded to the Token cloud or shared with any entity in Token’s network.
Merchants, banks, governments, and other organizations can store their private keys in accordance with their existing security requirements. Typical approaches are to use an HSM (hardware security module) or cloud-based HSM.
Member Users’ private keys are stored in their end user devices, including mobile phone apps and browsers.
|asset owner||Party whose asset is contained in the smart token; for transfer tokens, the payer; for access tokens, the grantor|
|access token||Smart token that provides authorization to access information or perform operations|
|AISP||Account Information Service Provider; for example, Yodlee and Mint|
|API||Application Programming Interface; for example, the underlying functions of the Token Java SDK|
|grantee||Token member who is authorized by another Token member (grantor) to retrieve information and perform operations on behalf of the grantor|
|grantor||Token member who authorizes another Token member (grantee) to retrieve information and perform operations on his/her behalf|
|HSM||Hardware Security Module|
|payee||Merchant that receives money in exchange for goods|
|payer||Consumer (end user or shopper) who makes a purchase and uses Token to pay the payee|
|PII||Personally Identifiable Information|
|PISP||Payment Initiation Service Provider; that is, online merchants|
|PKI||Public Key Infrastructure; rules, datastores, and trusted entities that manage public-key encryption|
|PSD2||Payment Services Directive 2|
|redeemer||Token member who redeems a smart token. For transfer tokens, this might be the payer, the payee, or another member specified by the token creator. For access tokens, the grantee|
|RTS||Regulatory Technical Standards|
|SCA||Strong Customer Authentication; a requirement of RTS for PSD2|
|SEPA||Single Euro Payments Area; payment-integration initiative of the EU|
|smart token||Authorization to access an underlying asset|
|SDK||Software Development Kit; for example, the Token Java SDK|
|Token cloud||Layer through which TokenOS members communicate|
|transfer token||Smart token that provides authorization to transfer assets, such as the funds in a bank account|
Copyright © 2019 Token, Inc. All Rights Reserved