Introduction

According to punching, the Nigerian Interbank Settlement System - NIBSS highlighted a significant setback to achieving efficiency in the electronic payment system such as the POS. Issue spotted was left at the prolonged transaction time which seems to linger even to date. Response time to transaction approval is due to the different backend configurations of parties involved i.e Banks and processors. This poses inefficiencies in the supposedly fast payment system. However POS transaction has witnessed a significant growth but not massive since inception until retrograded due to sacrificing speed for security (ie choosing security over scalability) - a serious dilemma eating down the financial sector. 

NIBSS spokesman, Shonubi, in Vanguard news disclosed there was 41,461 fraud cases whose statics between period 2014 - 2017 stood at NGN12.3B. Much of this incessant act was attributed to ATM, Mobile trail and across the counter frauds. This not only happen in this part of the world but across the world at large. An instance depicting the Central Bank's  exclusive involvement is in the Minneapolis report. 

With reference to law insider Settlement Payment may mean the transfer, or contractual undertaking (including by automated clearing house transaction) to effect a transfer, of cash or other property to effect a Settlement.

Niyi Ajao, acting Manager, NIBSS, affirmed :

“The total turn-around-time had been configured at 15 seconds in agreement with banks and processors. However, delayed responses from issuers after this timeout in recent times could cause authorised debits not to return to the terminal before the set TAT.”

Ajao explained that the timeout was the total turn-around-time for a POS transaction cycle from the time it was received from a POS to the time a response was sent back to the terminal.

Some of the remedial steps taken in March, he said, included the adjustment of timeout to 20 seconds from 15 seconds on March 14, 2019 and the adjustment of timeout to 45 seconds from 20 seconds on March 19, 2019.

He said the process was ongoing to disable any issuer with delayed responses beyond 45 seconds with immediate effect to isolate such a bank

Solution

The drawback to Settlement payment has overstayed even with the advent of sophisticated technology that would compensate for the lost value and time. But many financial gurus who are in the position to effect development proposals seems to be very convenient working in the old ways. Embracing new technologies is at uppermost low speed. Although, several factors could be responsible for non-acceptance of new-fashioned financial paradigm, but some day, we might wake up to see how far the world has left us behind. Then, catching up on it might require moving faster than the Peregrine Falcon. 

Blockchain technology presents ample opportunities for changing the way things work one of which is Decentralized financing (DeFi). The technology is famous for its secure, fast and immutable capabilities. It sees tremendous growth and development as enterprise and multipurpose businesses, individuals and government are diversifying. 

An instance of Blockchain technology is Algorand which offers a wide range of solutions/use cases to alleviate and/or solve financial challenges. Let us examine one of the uses cases. 

Algorand Standard Asset : Central Bank Digital Currency (CBDC) 

Stated on bis.org, the Central Bank developed interest in payment systems due to significant roles an efficient payment system plays with respect to:

• Economic efficiency 

• Financial stability 

• Monetary policy transmission; and

• Fiscal policy implementation

Algorand Standard Asset operates on Layer1 of the protocol hence inherits every functionalities that ALGO (native asset of Algorand) typically has access to. 

A Central Bank could issue a digital currency from ASA performing different or single purpose(s) to solve a couple of prevailing challenges facing Settlement Payment among leaf banks. Collaterizing assets as debt instruments might as well be worth considering. 

How can CBDC solve known problems?

Recalling punching, from adding to the speech made by Shonubi, CEO/President MAXUT - Mike Odusami, described the then solution thus: 

“Our solution as a technology company is really about fraud prevention and making sure that this is the person the bank authorises because most of the transactions are not physical, they are done through electronic channels.

“And also in the background, we are monitoring everything that is going on in the system, that is fraud monitoring and we have helped a lot of banks and financial institutions to do that,” he said

Preventing or controlling frauds should be exerted from the grassroots using the proper strategy (ies).  In the world of today, one barely sees the face of a thief where new compasses to bypass technologies continue to emerge. The thieves are very well informed how much guns and machines are in the armory for their chase. Blockchain can be very effective in locking out bad actors rather than picking up guns and start chasing after them. 

Financial fraud is a trend in the Inter-bank Settlement arena that is checkmate-able using CBDC. Algorand Standard Asset layer enriches assets with custom options i.e role-based such as revoking an asset from a target account tagged as fraudulent.

Transaction confirmation time or block finality sits around 5 seconds which is super fast to handle any amount of transaction together with its ability to scale amidst growing transaction volume. It's immutability and hybrid protocol can accommodate both centralized and decentralized economy. Perhaps, not an exaggeration for one to conclude that Algorand protocol has the potentials to curbing inefficiencies in the electronic payment system. As the apex bank, leaf banks would be coordinated to operate on a single or compatible closet to achieve a uniform transaction speed.

For proof, I have written few codes to demonstrate in summary why Algorand could be the best choice of route. 

Note: This section contains a tutorial to help you understand what a transaction is and the life cycle of an asset/token on Algorand Blockchain. Usual readers can flow along but best if you're a developer, perhaps Python developer.

Contents

• Setting up an end-point via third party API service. 

• Interacting with the blockchain. 

• Creating a Multi Signature account. 

• Singing a transaction.

• Creating an asset using a multi signature account. 

• Approving a transaction using multi signatures. 

• Asset/Token customization. 

Tools/requirements

• An API connection token - you can get one from Purestake. Deploying on Algorand Testnet. 

• Algorand Python Software development kit - SDK - Algorand developers resources

• Python application - python

• An IDE (code editor). I use pycharm for this tutorial. 

• The algorand dispense

Creating A Central Bank Digital Currency 

This section introduces you to setting up the requirements for getting an asset up and running on the Algorand ecosystem. Being a sub-asset of CBDC, we name it Inter-bank Settlement Asset - ISA

Some things to note

• We need an account's address to create an asset. But it makes more sense using a Multi signature account for this purpose. 

• Benefit of using a multi signature account is to decentralize authorization power to prevent unscrupulous acts attributable to a single entity. 

• ISA being a stable asset will have four customized roles separated from the creator account. 

- Manager account - a multi signature account with power to transfer, update or destroy an asset. (In this case, ISA)

- Freeze account - a multi signature account authorized to freeze and unfreeze an account holding ISA. 

- Clawback account - a multi signature account licensed to revoke asset from a target account holding ISA

- Reserve account - Can at any time mint ISA out of the total asset balance into circulation provided all of the 3 authorized accounts approve the transaction

- Destroy Asset: ISA can only be destroyed if the 3 accounts deem it fit.
         

• Leaf banks shall resolve to use ISA by opting for it, provided certain conditions are met. 

• Setting up a connection is super easy and the first step after your IDE is ready. Fig.1.0 features connection.py file. 

• Algo_address is the URL for Algorand Testnet. You should have it soon as you signed up on Purestake and logged into your dashboard. Same as Algo_token
• The Token is private to you and you need it to gain access to the network. See your dashboard. 

Fig.1.0

Now we have access to the network. We need an account to interact with the blockchain. To create a CBDC-ISA, as specified in the content above, it requires that we use a multi signature account so as to grant administrative rights and power to 3 different accounts belonging to whoever we have collectively agreed to be in the group of decision maker. So, we will assign 3 accounts for this purpose. The fourth account is assigned to the transaction executor which initiates the first and petty transactions. You will get a Mnemonic Phrase containing 25 words while you create an account using either the wallet interface or goal command. Alternatively, you could get an account using goal-less command from the python SDK:  "account.generate_account()" function which returns two values : a) a private key and b) public key. 

From the Mnemonics, extract the private and public keys

Fig1.1

Accounts_sk is a list of secret keys obtained from the Mnemonics. This is for demonstration purposes only. 

To get a multi signature account, we will amalgamate 3 of the public keys, result of which gives a public address, embedded in, is a hash of the trio. I have created a function called jointAuthorization(). Required_jointThreshold specifies the number of addresses we want to include in approval group. When this is done, the so called accounts' secret tokens must be provided to effect any transaction from the earlier created multi signature account. 

Fig.1.2

Line 73 registers the MultiSig account and we reveal the address in line 75. Notice that we are returning two values, we had only registered a joint account. The network remembers it whenever we return to make an approval, it searches the register, finds it and expects that we supply 3 signatures to execute our transaction immediately.

Fig.1.3

JoinAuthorization() registers only one joint account while we need four different MultiSig accounts for the four different roles in Fig.1.2 line 51 above. GenrateAuthorizationAccounts() executes jointAuthorization() three times and assigns result of each iteration to each role in asset_roles list. 

Note: logging is a python built-in module that let's us channel outputs to a desired file instead viewing from the terminal. It serves different purposes such as for debugging and tracking. Using it makes work a lot easier. 

Fig.2.0

Line 104 runs both JoinAuthorization() and generateAuthorizationAccounts() then we list out the joint addresses with their roles. 

Fig.2.1

Fig. 2.1 is a predefined function placed in a file getAssetId.py to obtain an asset ID soon as it is created. Although there are other ways to extract it but I'm more convenient using this method. 

Fig.2.2

Fig 2.2 displays the main file where we execute all modules connected to our program. Line 16 defines the function that brings the Interbank Settlement Asset - ISA to life. 

• There will be a total of 70,000,000 ISA in the asset's lifetime.

• Unit name is ISA

• Asset name is CBDC-Asset-1 connoting that it is one of all assets connected to the Central Bank Digital Currencies. 

• Manager account is set to joint approval account i.e the MultiSig account. Same as Freeze, Reserve, and Clawback accounts.

Fig.2.3

• Strict_empty_address_check is explicitly set to True. By default, it is True. With it present, there can be no accidental removal of an administrative role or a sudden destroy of an asset. So we can be sure that asset is secure from the protocol level except if expressly stated otherwise.

Remember we registered a multi signature object in the ledger in line 73 Fig.1.3, now we will make use of it to submit an approval transaction in line 39 Fig.2.3. Lines 44 to 46 put the signatures to work, obtain the three signatures and combine them along with the type of transaction we want to effect. Line 50 submit it to the network, returns a receipt or acknowledgment showing that we have a transaction waiting for approval. If the transaction is valid, it is approved else, it is rejected. This is what I termed an unfeigned government in codes. There is no one to bribe to try to manipulate signatures or signatories. It's either you input what you registered and get an expressed result or fake it and you get it all wrong. 

Fig.3.1

As the apex bank, we'd want leaf banks to opt in for ISA. Not a scenario where bankers operates on different assets/closets but desire for uniformity would obviously trigger efficiency in settlement payment. Our database captures every private, commercial, mortgage or other banks operating under the Central Bank's guidelines hence only recognized member banks can opt in for it. 

Fig.3.2

Calling the function resolve() checks: if caller is a leaf banks, if already holding ISA, if true, prints a message showing caller already subscribed for it and opts them in if condition evaluated to false. We will ensure it is callable only if caller creates an account or already possess an account in our self.member list. 

Fig.3.3

GenerateBankerAddress() produces an account, convert the private key to a Mnemonic and returns Mnemonic together with the public address to the caller. 

Fig.4.1

As the apex bank, we set a standard for leaf banks to hold any of the Central Bank's Digital Currencies . Upon issuing a clearance, it shall be resolved and ISA is added to their holdings. CanResolve() handles this section for us. 

There are five operations we can perform on this asset vis a vis :

• Update asset. 

• Unlock from reserve. 

• Freeze asset. 

• Revoke asset. 

• Destroy asset. 

I will discuss one of them. 

Revoking An Asset

Fig.4.2                                                                                                          clawback.py

Revoking an asset from a target account has similar transaction fields and parameters as creating an asset except that transaction has to be initiated from an account that we set as Clawback account at the time of registering asset on the blockchain. In our example, the sender being asset_revocation_authorized which is a joint signatory account, receiver is set to account that created ISA, and revocation_target is the account we want to revoke the asset from. Basically, the scenario portrays an admin exercising his power by subtracting value from an account adding it to another account. 

Fig.4.3 

Now we provide the signatories to validate the transaction. 

Fig.5.1

After transaction is successful, we scrutinize accounts of both parties for current balances. 

Successfully, ISA is created on Algorand testnet and searchable on the blockchain with ID: 10684835. To view it, copy the asset ID, on the top right-hand corner of the Algoexplorer page, switch from mainnet to testnet, then paste in the search column.

Draft.log (transactions details) 

Fig.5.2 

Fig.5.3

Fig.6.1

Fig.6.2

We have a leaf Bank - GTB with reference number "GT-13004" opted in for the Inter-bank Settlement Asset. Full code is available on the github. 

Going by this demonstration, run the code to evident the speed and mode at which transactions are finalized on Algorand Blockchain. More research can be made to discover further exciting use cases of Algorand solutions. We could have decentralized finance operating in a centralized environment to reset financial and economic imbalances such as controlling: fraud, laundering and so on and achieving efficiency in the electronic payment system. 

Resources

• Algorand Website

• Developers resources

• Code

• Python

• Purestake

• pycharm

• punching

• Law insider