TDNSYS system is centralized, based on the client server model. The infrastructure supporting the TDNSYS relies on existing, reliable and proven state of the art technologies in the Financial market infrastructures (FMIs). It is very similar with the infrastructure required for Credit or Debit Cards. The communications between the Server and the Clients takes place over private or public networks.
The Server side is implemented and maintained by the Central Bank and exposes a public API supporting all the transactions related to TDNs.
The Clients consist of a Central Bank website and hardware/software systems developed by IT companies
based on the API. Holders of TDNs can request ownership, split, consolidate and
assign a
In the figure above redundancy and disaster recovery is implemented by storing data on multiple servers in different data centers. This makes data available almost 100% of the time. Promoters of DLT consider client server systems as having ‘one point of failure.’ This may be true for simple systems, but in the financial industry this is not the case. I should also mention that applying blockchain’s feature ‘Irreversibility of Records’ to data stored on Fed systems or store this data on some computers somewhere on the internet is just plain ridiculous.
Implementing the server software is not a technical challenge. It consists of an ISAM database, ACID compliant, containing the main TDNs table and administrative tables. The TDNs table supports only insert and update operations. Records are never deleted. The administrative tables include information available when a transaction is performed. They also support a case management system used for storing investigation information regarding complaints and fraud.
Each TDN has one record in the repository. At the minimum the record contains the
The
If privacy is not a concern of the TDN holder the PKI field can contain a digital certificate issued by the Central bank. This may even be required if the holder of the TDN accepts payments. The banks must always sign the TDNs with a certificate issued by the Central Bank.
The TDNSYS must support great volumes of transactions and store very large number of records. It has to be very fast, redundant, with high availability with no down time. There is no need to get into the details as such systems are routinely deployed in the financial industry.
A TDN client consists of hardware, software and means of communication with the TDNSYS server and with other clients.
The means of communication already exists. The Internet is widely available and the banks have their private networks ready for use by the TDN applications.
TDN client hardware can be any of the shelf digital devices or specially design machines. They may be PCs, MACs, smart phones, tablets, smart watches, etc. Special hardware is needed for cash registers, bank teller terminals, ATMs and vending machines. This hardware may already be in used and only software updates may be necessary in order to support TDN transactions.
Hardware platforms use different technologies for performing input/output operations and TDNs storage.
The hardware necessary for storing TDNs can be any device able to store digital data. This can be a hard drive, a smart card, a smart phone, persistent memory on a memory stick, card or wristwatch.
TDNSYS exposes an API and anybody can design applications using it. These applications can be deployed on a large variety of hardware platforms. Brick and mortar stores can deploy cash registers and apps for mobile devices compatible with these registers. The buyer will run this application on his/her digital device. The buyer does not need an account with the seller. A generic application may be design for mobile devices and as long as all the sellers agree to a cash register standard. The basic interaction between such a generic app and the cash registers will consist of the following operations:
Here are some examples of clients: