This post is part of a series on a project I am doing to build banking architecture.

In the previous post I discussed using the blockchain as an immutable distributed database store, for handling transactions and more. As with most initial proposals there are several problems associated with using the blockchain in this way, most immediately the fact that there is no incentive for mining the blockchain as Bitcoin is removed. These problems can be addressed, however this post will focus on using another distributed database.

After putting some thought behind the best way to architect a bank, I believe I have come up with at least an alpha candidate. Any infrastructure setup for a bank should have the following traits:

• Highly available
• Secure
• Client server topology

Highly available

One of the biggest strengths of using the blockchain is the distributed nature of the storage system. Having a single point of failure is a dead-end for most production applications, and if a single (or multiple) nodes go down the system should function normally. Distributed architecture is key for this to happen, especially when it comes to the database store.

There are numerous database solutions that offer a distributed architecture, and one of the most compelling is RethinkDB. RethinkDB promotes itself as a scalable database for the real-time web which uses a distributed architecture, a robust query language and complex relationships. For a financial institution working with more than non-trivial data (e.g. more than just time-series plots) this is all necessary functionality.

Secure

Security for the data read and written is absolutely necessary. The network should be solid with paths protected from interference and manipulation, transactions should be immutable, and trust should be guaranteed.

Network level security is highly documented and should be implemented using industry standards and best practices, and can be implemented along these lines with a large degree of confidence. There will always be room for improvement, and this should be iteratively applied as the stack matures. As such, this will not be a major focus of this post without writing down the importance of this security layer.

Immutable transactions can be achieved using cryptography to ensure the validity of the contents of the message. Again, there are numerous industry best practices regarding this, and they will be one focus of ensuring trust in the network.

One of the best ways to ensure trust is by using public key cryptography. Each client and server will have their own set of keys which will be used in the encryption of the messages, ensuring that only the intended participant can read the message. The handling of keys will be discussed in the Architecture section of this post.

Client server topology

The structure of the system should be based on client-server topology. In this system, there will be clients, the consumers, and the server, the bank. Clients will communicate to the server directly and the server will handle the transaction accordingly, using the distributed database to broadcast the message to relevant parties.

A consumer may have multiple clients attached to their account (mobile devices, web browser, tablets, etc) and each will use the public key cryptography to ensure ownership of messages.

Architecture

With the above functionality in mind, we now look into the architecture of this system.

So far we have: clients connecting to a server using public key encryption, that server reading the relevant data and processing accordingly, and then dropping that data into a distributed database store. Other servers will then pick up relevant data (to them) and process, updating any relevant accounts and notifying clients.

In this system, each client and server will have their own keys. A user will register his keys against his account, where each of his devices will have a key pair. The user will have his bank’s public key on his devices, ensuring that communication can only happen between his device and his bank, and that any other parties will not be able to decrypt said communication.

Each bank will have their own key-pair as well as key-pairs of all other banks in the system. Interbank communication will then be encrypted using these keys. All banks’ public keys will be available on the network through the distributed database store. Keys will only be able to be added to the store through a specified security mechanism and relevant validation, as banks are currently only given licenses by their relevant fiduciary authorities in their territory.

The distributed database will only be accessible by banks who are approved. This can be done through the network layer (e.g. an account on a VPN) as well as database read/write access through a database user where each bank will have their own user.

Banks will have their own branches write to the store using separate credentials. Branches will not do any processing but will act as clients on behalf of the bank, and will have their own key pairs. Communication between the branches and main bank will be done via the document store.

The bank will have multiple main processing servers in order to ensure high-availability. As the user should only carry one key for the bank, these main processing servers will do key sharing through internal public key infrastructure, employing processes much along the lines of SSL Certificate Authorities. This will allow messages to be validated and decrypted at all nodes of the processing server network.

Each bank processing server will watch the database for relevant transactions. These transactions could look as follows:

{
    bankid  :   [ unique bank identification ],
    message :   [ encrypted blob ],
    timstamp:   [ unix timestamp ]
}

A bank would listen for transactions relevant to itself, and then decrypt accordingly. There would be several tables, including a main one for transactions, as well as one for keeping the public keys of all banks. These keys would be used in the case when a transaction affects a user at another bank - an interbank transfer. The message would be processed, and then re-encrypted for processing by the relevant bank.

On transaction process the customer will be notified, again using public key encryption.

Internet banking using public key encryption would take some adjustment to current procedures to implement. One implementation would be for a user to have a key pair that is stored on a thumb drive or in browser, and then accessed through a plugin.

Conclusion

The above architectural implementation will provide a fault-tolerant, highly available infrastructure for a financial institution. Using cryptography we can help ensure communication is trusted and unchanged, while ensuring a good experience for the user.