TPPs versus Resellers

First, let's review what a third-party provider, or TPP, is in the context of Open Banking.

An organisation which interacts with a bank to provide services to consumers is a third-party provider. TPPs enable customers to make and receive payments directly from a bank account, make better use of their financial transaction data, or benefit from new card-based offerings. In the sense that the first party is generally a bank customer and the second party is typically the bank, the technology provider that connects them together becomes the third party. Put a different way, in a traditional relationship with a bank, the consumer interacts directly. In Open Banking, the consumer interacts with the TPP, which then interacts with the bank on the consumer's behalf.

TPPs can choose to integrate with banks on their own or through an aggregator. A Technical Service Provider (TSPClosedUnder PSD2, a Technical Service Provider renders purely technical services, usch as the processing and storing of data, services for privacy protections, and the provision of IT and communication infrastructure, without entering into the possession of funds, whilst also not qualifying as a PISP or AISP.) is one type of aggregator; a Reseller is another type. Token is a TSP. Aggregators providing Open Banking connections hosted on the Token Platform to other TPPs are Resellers.

The Token Platform supports two types of TPPs: (1) TPPs that provide Open Banking services under Token's licence and (2) TPPs that provide Open Banking services under their own licence.

By regulation, TSPs like Token render purely technical services only — processing and storing data, privacy protection, and/or providing an IT and communication infrastructure — without taking possession of transacted funds or a user's account information, never directly handling funds and information in the role of either a PISPClosedPayment Initiation Service Provider – a TPP that initiates a payment order at the request of the payment service user with respect to a payment account held at another payment service provider. or AISPClosedAccount Information Service Provider – a TPP authorised to access consumer or business account data from the account holder's financial institutions with the account holder's explicit consent..

Resellers can leverage the Token Platform as a hosted TSP, a PISP or AISP or both. In general, Resellers can offer TPPs faster launching in a new market, access to compliant interfaces, technical simplicity, a single integration, and the convenience of using the Reseller's own verified eIDASClosedElectronic Identification, Authentication and Trust Services – an EU regulation on electronic identification and trust services for electronic transactions in the European Single Market. See https://ec.europa.eu/ digital-single-market/en/discover-eidas for the rules and regulations. credentials for safe, secure access to the ever-growing network of Token-connected banks. Resellers can also assist TPPs that want to operate under the TPP's own licence and/or provide proprietary interfaces to sub-TPPs hosted on the Token Platform.

Within the Token ecosystem, TPPs are classified by four types:

  1. TPPs using Token's licence
  2. TPPs using their own licence
  3. TPPs using Token's licence with Partner Permissions
  4. TSP-Resellers using their own licence with Partner Permissions

When granted Partner Permissions by Token, TPPs using Token's licence register, onboard and manage their own sub-TPPs (merchants and/or PFMsClosedPersonal Financial Management – refers to software that helps users manage their money. PFM often lets users categorize transactions and add accounts from multiple institutions into a single view.). By contrast, a TPP operating under its own verified NCAClosedNational competent authorities are organisations that have the legally delegated or invested authority, or power to perform a designated function, normally monitoring compliance with the national statutes and regulations. licence extracted from its validated QSealCClosedQualified eSeal Certificate – “seals” app data, sensitive documents and other communications to ensure they are tamperproof and originate from a trustworthy source. or QWACClosedQualified Web Authentication Certificate – certificate that validates your identity and role as a Payment Service Provider to your customers and other business, while encrypting and authenticating sensitive data. can opt to administer its own realmClosedThe services, feature set, functionality and contents supported by an Open Banking services provider. A bank's realm, for instance, comprises the Open Banking services and products supported by a particular bank. The Token realm comprises all the services and feature content supported by Token as the TSP; whereas a Reseller's realm is restricted to the services and feature content administered by a particular Token Reseller under its reseller agreement with Token. , creating and maintaining its own bank connections. The preferred paradigm for most TPPs with Partner Permissions, however, is to operate under Token's realm to onboard and manage sub-TPPs.

Diagrammed (hover to enlarge), these Token-Reseller-TPP chains take the respective forms that follow.

1. TPPs Using Token's Licence

The TPPs in this category operate under the aegis of Token's licence, inheriting Token's bank configurationsClosedOpen Banking registration entailing bank-required certificate and key exchange with signing authority. When successful, TPP receives a client ID and client secret as an approved PISP and/or AISP with the bank.. Identified by a unique memberId, granted access using their own API authentication credentials, these TPPs can create and maintain user accounts, providing Token-hosted Open Banking services (PISClosedPayment Initiation Service – with the consent of the end-user, initiates a payment from a user-held account upon user authentication., AISClosedAccount Information Service – supports TPP secure access to customer accounts and data, but only with the bank-verified consent of the customer., and/or CBPIIClosedCard Based Payment Instrument Issuer – a payment services provider that issues card-based payment instruments and allows its customers to pay from bank accounts.).

Use Cases. Clients wishing to use Token's licence and integrate its API and webapp interface to connect with banks as simply as possible.

2. TPPs Using Their Own Licence

TPPs in this category operate under their own licence. Creating and maintaining their own bank registrations and configurations identified by their unique memberId, they are granted access using their own API authentication credentials, which allows them to create and maintain user accounts and provide Token-hosted Open Banking services.

Use Cases. TPPs with their own license wishing to use the Token API to connect to banks but which do not require any further structure in Token's environment for their clients.

3. TPPs Using Token's Licence with PARTNER Permissions

TPPs in this category are like TPPs using Token's licence in the first category, except that these TPPs have been granted PARTNER permissions. This means that they can create Sub-TPPs that also operate under Token's licence. A unique actingAs.refId assigned when onboarded is then verified against the Sub-TPP's Open Banking permissions in each API call made on its behalf by the TPP-Partner.

Use Cases. TPPs wishing to resell Token's licence using the same API credentials for each Sub-TPP client.

4. TSP-Resellers Using Their Own Licence with PARTNER Permissions

TPPs in this category are true TSP-Resellers operating under their own realm, rather than Token's, supporting (a) sub-TPPs using the Reseller's licence, as well as (b) TPPs using their own licence. Identified by a unique memberId, these Resellers create and maintain their own bank registrations and configurations, and are granted Token Platform access using common API authentication credentials, which allows them to create and maintain user accounts and provide whitelabel interfaces and functionality to onboarded sub-TPPs. At the same time, these Resellers can also support TPPs operating under the TPP's own licence.

Use Cases

  • Token TPPs wishing to whitelabel and resell the Token API under a partner agreement and who therefore require a unique memberId for each merchant they support
  • TPPs that abstract the Token API for use within their own API
  • TPPs wishing to streamline the API credentials needed to interact with configured banks
  • TPPs that want to support TPPs with their own Sub-TPPs, as well as TPPs that use their own licence

* * * * *

New TPPs register and onboard by creating a Token Dashboard account. TPPs with Partner permissions register new Sub-TPPs via the dashboard.

To obtain Partner permissions, contact your Token representative for assistance with setting up a reseller account. Once the required partnership agreements have been executed, you'll receive unique login credentials that allow access to the Dashboard's TPP Manager and other reseller functionality, from which you can create and manage new TPPs and/or Sub-TPPs, as appropriate.