[#45] What is needed for the Finternet to scale? Hint: It's Tokenization & Encryption Protocols

Fundamental issues in current systems, such as lack of transparency, data security, tokenization, and encryption can all be solved on the blockchain

There was a whitepaper published in April 2024 on the concept of the Finternet, which you can check out here.

It basically talks about how the future of financial transactions lies in distributed ledger technology, and interconnected ledgers. Which is basically a blockchain of some sort, or multiple interconnected blockchains, on which financial systems are built. Sounds fancy. But is it really needed?

The need for the finternet: we’ve optimized silo’ed systems as much as we can

I had written a piece some time ago about how the future of payments across the world, especially for cross border transactions, and financial inclusion lies with blockchain based payments. You can check out the article here:

[#39] Is the future of payments in the "Finternet" era powered by blockchain?

---

The reason is fairly straightforward. We’ve come to a point where we’ve optimized to almost as much as we can with regards to speed of payments, and settlement systems. It’s been more than 10 years since Payment Aggregators first became a thing (Stripe was founded in 2009), and real time payments, which solve for real time money movement, has been close to 15 years (Pix was launched in 2020, and UPI was launched in 2016). And problems exist:

1. Multiple systems that don’t talk to each other: Acquiring bank, issuing banks, networks, payment aggregators, payment gateways, and merchants operate as silos. Because there is constant transfer of information from one party to another, it leads to delay in settlement times, and complexity in refunds and reconciliation

2. This problem is magnified when it comes to cross border transactions: A layer of complexity is added, with regards to authorization, and money movement: it has to be compliant with country regulations.

3. Data sharing: Broken customer experience, and dependency on banks, which only allow sharing, even through licensed 3rd party providers at limited time periods, and may share incomplete data, or may choose to not share data as well.

Open banking in India is still lacking in security, privacy, and customer experience:

The Account Aggregator framework in India was supposed to solve for a lot of the data sharing & financial inclusion. But its not. It’s still quite challenging to share bank data with 3rd party providers: customer experience is not solved for, and data security and privacy is a massive question mark. While Account Aggregators have tried to solve for some pieces of this, there is still very big gap in security of data, and visibility on what it is used for. As a result, banks a reluctant to share the data, and for unbanked, or underbanked individuals, this presents another barrier to financial services. We’ve tried to create some sort of central database for identity and information: Digilocker, CKYC, Aadhar, but for those of use who have tried to use it, it is very far from an optimized solution. Errors, failure to retrieve information, downtimes, and data quality have prevented these solutions from scaling. Open banking in India is still lacking in security, privacy, and customer experience:

And of course, the problem here is fundamental: The systems are still siloed, and separate. So there is only so much optimization that can be done with regards to operations. You can check out my piece on Open Banking, and the gaps that currently exist in the Account Aggregator framework below:

---

---

And that’s the vision of the finternet: Interconnected and customer centric financial systems, which allow information sharing in a seamless & secure fashion.

1. All the different financial systems speak to each other since they are either built on the same blockchain, or different interoperable blockchains. And since blockchains are built on distributed ledger technology: this means is that every system plugged in has a record of transaction ledger, making it 1) Harder to fake and 2) More transparent for everyone.

2. The customer can enter into the Finternet by logging into any of the systems: Banking App, by doing a payment at a payment aggregator, by logging into their investments portal, or anywhere else.

3. After customer consent, financial details tokenised and stored in a central identity ledger: Reduces dependency on bank to share data: Customer consent is taken, and the information → which could be payment details, identity, PAN, Aadhar or anything else is tokenized and stored in a central identity ledger. This ledger would also need to have an off chain token vault where the original data is stored, and validated when required.

4. Encryption needed for transaction / dynamic data: In some cases: transaction / payment data is needed, or the information is dynamic in nature: things such as investment details, stock / MF / FD valuation. There are two ways to do it:

   1. Either this information is pulled only when the customer requests it, and thats when the systems on the blockchain communicate with each other to encrypt, share and decrypt the data.

   2. The data is stored in a central ledger, and periodically refreshed as and when required. The intervals for refreshing can be pre-decided: daily / quarterly / weekly based on the financial institution comfort.

This is also purely a backend process - ideally for the merchant & customer nothing changes:

Example: The customer comes and initiates a transaction, or a process to get a loan, or anything else, either on the bank or the merchant touchpoint. All the authentication, token retrieval, validations, fiat conversion to CBDC and back should be done by the banks, the blockchain, and the payment aggregators / processors. No additional onboarding, save for some sort of consent layer is required by the issuing or acquiring bank.

Currently, there are start-ups, chief of them being Bridge, which was recently acquired by Stripe, which provide cross border settlements through stablecoins, but this requires the customer to link a fund source to the Bridge wallet, and the merchant to be onboarded, and have a Bridge wallet created. This is a good “in-between” solution, but in my opinion may not scale.

---

Example of how Bridge settles in stablecoins

---

But then what is needed for financial systems to become: “The Finternet?”

It’s easy to say: “Oh, interconnected systems on a blockchain.” But what actually needs to happen for this to become a reality?

1. Authentication: Authentication is primarily customer facing, so this doesn’t need to change. But when entering into the finternet, identity verification would need to be more stringent: just SMS / OTP may not be enough, especially when giving consent to store or share personal data.

2. Tokenization of customer details, and storage in off chain token vaults to prevent secure data from being shared

3. Encryption: Some types of data needs to be encrypted & decrypted: in the case of actual transaction data needed for alternate credit scoring, just tokenized information won’t work.

4. Thinking that all systems will shift to a blockchain is a little too far fetched. Instead, there will probably be a combination of fiat and blockchain systems, which will need to speak to one another. Example: 1-1 mapping between a fiat Rupee and a Digital Rupee to ensure reconciliation of account balances happens seamlessly. The customer will be paying through fiat, but the settlement will happen on the blockchain through the CBDC.

5. These CBDCs will need to have the capability to exist on multiple chains: From an implementation perspective, each financial system should have the flexibility to build its system on the blockchain it most prefers. There should not be a central mandate for this, and hence interoperable blockchains and tokens are needed

Authentication in the Finternet: Existing methods work, but need to have more fool proof methods layered on top to protect fraud

Several layers of authentication would need to be built in. Step 1 is login, when a customer is logging into their bank system, which currently is done through SMS - OTP. Newer solutions such as Silent Mobile Verification, pioneered by companies such as Sekura & Bureau Id, which verify phone number & device using mobile data are also coming to the fore. And then you have passkey based solutions: which are more secure than passwords, since they use cryptography, and a public - private key pair to authenticate, and are linked to devices. All of these authentication mechanisms can act as layers to further enhance security.

Mastercard Passkey (which was recently piloted) allows customers to tokenize their card details using cryptography, and public-private key pairs, which sits behind a layer of biometric credentials.

Tokenization is key for data sharing: Authentication just solves for entry into the finternet. There needs to be a way to secure the personal data of the customer: saved payment methods such as cards, identity details such as PAN, Aadhar, Drivers License number etc.

There are different types of tokenization: There’s something called Card on File, which is merchant specific: i.e. the details used to tokenize the card are merchant specific, and then there is Device tokenization, where the token is stored in the device, and while can be used across multiple merchants, is linked to that device.

Some sort of Network tokenization would have to be implemented here: Ex example being card tokenization by VISA / Mastercard. Once a customer has tokenized their card, it can be used across the network, using some sort of merchant identifier.

Example: in this case, the blockchain needs to have a tokenization system, that stores the original data off chain, and the generated tokens are stored on the blockchain, and can be retrieved using a customer identifier, such as a customer ID, or a phone number. This then adds that extra layer of security when transferring customer personal data, and ensures no unneeded exposure of data. It also allows all merchants, and systems who are plugged into the blockchain to use this token, and doesn’t just restrict it to a merchant or a device.

Tokenization works to secure static data for transfer on the blockchain: But what about actual transaction / payments / investments data which systems may need? Here the actual data is required, and hence a layer of encryption is also needed

In this case, while something like a token vault is needed to store the data off chain, there also needs to be a layer of encryption / decryption. That’s also the problem that currently exists with Open Banking: consent management is barely there, and once the information is shared, since its unmasked, and there is no control on usage: there is no visibility on who or what is using this data.

Case in point: I’m 99% sure every super app is using my data, and selling it. Over the years spam calls and messages have only increased, and I’m getting them from places I know I have not shared my data myself. In-fact (and this is a personal opinion), I got off Cred, because their request to read my emails and SMS’s was going a bit too far, and the matter of fact way they couched that request freaked me out. (“We’re doing it to improve your experience: Yup, that and sell my data!”)

So solutions being built for secure encryption & decryption of data, and in a way that prevents its from being shared ahead:

There’s an interesting whitepaper that you can check out here, by Silence Laboratories, co-authored by Jay Prakash (you can connect with him here) that goes into possible solutions around this in more detail: but basically it suggests cryptography, and distributed key generation as a way to encrypt and share data with the data requestors (or the FIUs in the AA system).

In this case, Distributed Key Generation (DKG) facilitates secure data requests by using cryptographic key pairs where:

• User consent is obtained before any data exchange occurs, and explicit details about data usage are provided.

• Data is encrypted using a public key generated through DKG.

• The corresponding private key is split into secret shares, and split among multiple parties, ensuring that even to decrypt the data, some sort of collusion has to happen. Unauthorized sharing of data is prevented through collaborative decryption requirements and session-based keys.

• Sharing data after decryption: systems can always be put in place, such as audit trails, and preventing the duplication of the data, or it exiting out of the system. It’s not perfect, but its atleast more secure than the current system today. And because new key pairs are generated for every data request, the usage of data can be closely tied to the type of consent & authorization given, and tracked by the type of key pair generated.

This approach enhances both security and user control over personal information in financial transactions.

Open Banking can optimize the current processes, but can’t fix fundamental issues that exist

Data Security: Consent management, what the data is used for after sharing, tokenizing, & encryption don’t exist currently

Speed of Settlements & Recon: Multiple hops, systems operating in silos - while Open Banking can optimize it, fundamentally in the current system everything will work in silos.

The Finternet: Authentication, Tokenization & Encryption are what will ensure if this succeeds or fails

Data Security: Solved through

1. Tokenization: Tokenizes customer payment methods, and identity details to prevent constant exposure while transferring data. It also prevents unauthorized parties from using this data, even if they get their hands on the token, since it cannot be reverse engineered to get the actual details / numbers

2. Encryption & Decryption: Computational logic, and fragmented sharing of data to encrypt and decrypt actual transactional and payment data that may be needed to be shared. Again: makes sure that only authorized parties can use this data,

3. Authentication: More secure ways of logging into systems: using SMV, biometric, and passkey based solutions, but this is regardless of the Finternet. This can happen in today’s systems as well.

Speed of Settlements & Recon - Solved through Blockchain

This is a fundamental strength of the blockchain: because it utilizes distributed ledger technology, all systems plugged in have a copy of the “ledger” and full details of all the transactions that have happened, which are immutable, so ideally there is no need for reconciliation, and money movement can happen instantly.

And solutions for fiat & blockchain systems working together, both on & off chain, to ensure that customer & merchant experience remains optimal, is what will make it scale.