Use Cases

A Truly Compliant Decentralized Open Finance Solution

What is Open Finance?

Before looking at why Open Finance is difficult to implement, we will explore what Open Finance is. As the UK Financial Conduct Authority states, “increased use of data and technology is changing how our financial markets work”. An example of this lies in open banking, in which consumers are able to grant access to their banking data to third party providers who can provide new services. Digital first banks such as Monzo have been quick to allow third-party providers to build on their platform, but even traditional banks such as HSBC and Lloyds have begun allowing open banking services.

This shift is driven in part by recent regulations such as the Payment Service Providers Directive 2 (PSD2). PSD2 is a European regulation that aims to better protect consumers, but also to boost innovation and competition in the sector by allowing new companies to enter the space. Examples of PSD2’s impact can be seen in the need for customer authentication on electronic payments or the requirement for banks to release application programming interfaces (APIs) that enable third-party providers to access bank accounts to build new services on top.

APIs allow individuals to share information across companies. It works the same as how you might use Uber; the Google Maps API allows Uber to see where you are located and for you to see where your car is. By using APIs, individuals do not have to share log-in information. This means that instead of giving your banking log-in and password to a third-party, you can simply grant access (usually through a link) that achieves the same result.

Open Finance works in the same way. However, while open banking is focused on payment account data across retail banking, Open Finance is focused on wider financial services including mortgages, investments, pensions, insurance, and credit.

Why is this difficult?

There are several difficulties involved in a global Open Finance platform (also known as Open Banking, within which PSD2 is a major governing factor).

The first is regulatory. Different countries have different rules and are still clarifying what Open Finance will entail on a basic level. While the UK has been ahead of much of the world when it comes to open banking, the FCA has only recently put out a call to participate to institutions to define exactly what Open Finance will look like. Other countries are either going through similar exercises, or are yet to begin. Despite the interconnectedness of the global financial system, rules and regulations vary wildly across borders, and therefore regulators will move at varying speeds and in different directions.

The second difficulty is institutional buy-in. There are several reasons why institutions would be reluctant to participate in Open Finance. Any new system or platform that institutions need to create or join is likely to incur costs. They may also be fearful of the stated aim of PSD2 and other regulations in encouraging new competition to their business, and in particular well-funded FinTech firms that are already making their mark across the sector from banking to trading to pensions. Furthermore, firms must adhere to the wider regulations of the jurisdiction in which they operate, which may prohibit certain aspects of Open Finance. This may include issues in securing data and user privacy.

Finally, it is tough to build a global Open Finance platform that allows for the interoperability and usage required for it to be successful. In addition to the problems outlined above, there are issues in defining common standards that fit not only a wide range of firms based in different countries, but also a spread of companies from different sectors. Banks operate in a different way to insurance firms; pension funds do not operate in the same manner or to similar regulations as credit card companies.


Improve the experience for all stakeholders (including users, developers, and institutions) by building a platform that can:

  • Connect financial services companies worldwide
  • Host third-party developers
  • Allow investors to retain control of their information
  • Ensure firms are compliant with all data and privacy regulations

AllianceBlock seeks to be the bridge between TradFi and DeFi. One part of this entails being able to share data in a compliant manner while leaving the user in control of access at all times. To achieve this, the AllianceBlock protocol will act as a gateway that not only allows financial institutions to plug in, but that can also plug in multiple data sources (such as KYC and AML data). For more details about this, you can read our detailed Data Tunnel roadmap here.

The AllianceBlock protocol allows all capital market participants to interact to both benefit themselves and the end user or investor. This is done through the three layers that form the protocol, as outlined above. These layers combine to enable us to meet the challenge laid out.

1. Connect financial services companies worldwide and host third-party developers

AllianceBlock is built to be easy for firms to utilize. It can be integrated into legacy infrastructure through connecting to bank’s APIs, but it is also future proofed owing to being built to use APIs from the beginning. As previously explained, this use of APIs is crucial to Open Finance and it means that retail banking APIs will be able to connect to DeFi in a way that is compliant with financial regulations such as PSD2. It is not only TradFi firms who can integrate AllianceBlock, but also DeFi projects.

This is one of the reasons we have partnered with Ocean Protocol. We will be the link between the institution’s API and the Ocean Protocol data layer. Through this, DeFi apps will be able to access banking institutions API in a compliant manner, allowing them to build new products for banking customers.

For example, in our Private Banking case study we discuss bridging DeFi and CeFi to offer private banking individuals short term financing on illiquid assets. To achieve, this, we are building a data pipeline that sits on top of Ocean Protocol. User data such as KYC and AML will be stored here, and users will have role-based access control (RBAC) which will enable them to allow and revoke access to their data. This will allow private banking customers to access peer-to-peer lending products.

2. Allow investors to retain control of their information and be compliant with all data and privacy regulations

This RBAC mechanism is a crucial part of our data governance layer, as it is an important part of financial regulations. There are a number of elements that make up this data governance layer.

Data Layer The Data Layer stores data relating to investors and issuers. This includes KYC and due diligence information, eligibility statuses, transactional data, and legal ownership statuses of digitized securities. Data is stored both on the Data Layer and the user’s devices. The investor can then share their information, as above, by simply sharing their API access key with the chosen entity.

Once the entity has this key, they can use the AllianceBlock protocol to query for the user data. They must prove their compliance and requirement to access the user data, a secondary check designed to protect users from phishing, hacking, and honeypot attacks. Even if the malicious actor can gain the user’s private key, they will still be prevented from accessing the user data, as they will fail the secondary check on compliance and requirement. The user’s data wallet synchronizes to the Data Layer, and other approved users (such as providers and institutions) can view the selected data to be shared, but not edit it.

StorageTo store data in a decentralized and secure manner, we use a combination of technologies:

  1. Our Data Layer is the frontend of an Inter Planetary File System (IPFS) powered architecture. IPFS works in a similar fashion to BitTorrent; users host information globally so that it is spread across many different operators, rather than one central point of failure. It is also compliant with GDPR, owing to how it operates.
  2. Zero-Knowledge Proof based validation (ZKP) ensures compliance with data privacy laws while simultaneously being error-proof. ZKPs allow two different parties interacting on the AllianceBlock protocol to share information in a secure manner. They allow the proving party to prove to the verifying party that they know a value x, without sharing either the value itself or any other information. A case study explaining how this works on the protocol can be found on page 34 of our whitepaper.

Only the data owner will possess the knowledge of the data encryption keys or the data’s storage location. Without having both pieces of information, no-one else can access the data.

Cross-borderThis data storage and sharing is then verified through an automated verification of the requesting entity’s credentials by the Cross-Border Compliance Layer (CBCL) which will assess against both the jurisdiction of the investor and the requesting entity. This is important, as it allows Open Finance to become truly global. More information on how the CBCL works can be found in our case study on cross border activity.

Benefiting ALBT holdersALBT is integral to AllianceBlock protocol. The Open Finance solution described above is only possible with the use of the ALBT token.

The AllianceBlock ecosystem benefits both data publishers and data consumers. Users are incentivized to share it as they can monetize their data, while also remaining in control of access at all times. There are a number of actions that necessitate the payment or receiving of ALBT in this case study, including:

  • Data query: Each request for data is paid in ALBT tokens
  • Dataset generation: A dataset generation is a more complex data query and commands a (normally higher) fee payable in ALBT token
  • Data collection:Collection of data from integrated streams is incentivized with ALBT
  • Storage: Storing files on IPFS is paid in ALBT
  • Processing: Processing data across ecosystem and to integrated systems requires ALBT
  • Data distribution: Network fee is required to redistribute the data to ecosystem actors
  • Data analysis: Obtained data analyzed using various mathematical methods requires ALBT
  • Data replication: Network fee is required in order to replicate the data
  • Data extraction: Network fee is required to extract the data to different data formats (e.g. .csv)
  • Data validation: Compare two data sets to check data accuracy requires a network fee

AllianceBlock Protocol’s APIs will be one of the pioneering foundations of the Open Finance/Banking space and will adhere to the spirit and intent of PSD2. It will enable wider access to a range of institutions and third parties to develop their own apps, fostering innovation in the space. Just as APIs have enabled tech firms to leverage each other’s capabilities, so too do we believe that AllianceBlock will be capable of unlocking new solutions across the financial services space that we may not even be able to envisage at present. Through doing so, we will also provide value to ALBT holders who will benefit from the usage of the protocol.