Transferable Digital Notes Project

TDNSYS Infrastructure

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 PIN or PKI to these TDNs using the Central Bank website or the proprietary hardware/software clients.

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 TDN Signature, the associated value, date when issued and the date when the record was updated. The update date, PIN and PKI may be null, all the other fields must have a value. The record is inserted when the TDN is issued by the Central Bank.

The TDN Signature is a string of numbers containing a timestamp, a long unique number and the value zero padded. The status can have the following values: ACTIVE, CANCELED or BLOCKED. The status of a TDN can be accessed by anybody with access to the TDN Signature. The PIN and PKI support TDN security and can be set and updated using the Central Bank website or any other available application. If the PIN is set it has to be included in the API request and it is validated against the store value before a transaction is performed. If the PKI is set the security test is performed by encrypting a string using the public key stored in the record and compare it with the decrypted value returned by the holder of the TDN. PIN and PKI cannot be both set.

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.

  • Webcams
  • The user will be able to read the TDN barcode representation in the appropriate input fields of a webpage or application.
  • Barcode readers, wand barcode scanner
  • Standard equipment on cash registers, vending machines, ATM and other specially purpose hardware.
  • Smart Card Readers
  • Digital devices may have built-in card readers. Card readers can also be purchased separately and attached to most digital devices. Cash registers, Vending machines, ATMs already have these input devices built-in.
  • Direct communication between the buyer's and seller’s devices
  • Bluetooth technology is widely supported by digital devices. Wi-Fi and other local networking can be also used for this purpose.
  • Near-field communication (NFC) cards and devices
  • For output digital devices can use digital displays, printers and the devices already mentioned above.
  • Manual input/output
  • In the situation of a digital device with only a keyboard and mouse the user have to manually cut and pasted the TDN's text representation into the appropriate fields of an applications or webpage. This may happen also when an application or website does not support other input/output devices besides keyboard and mouse.

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:

  • Buyer accepts the amount due displayed on the seller's cash register. (this step can be skipped)
  • Seller's cash register reads a bar code displayed on the buyers mobile device screen showing the value of the TDN stored on the device.
  • If this value is the same with the amount due the seller's cash register request the TDN ownership.
  • If the TDN value on the device is larger than the amount due the cash register request a split for the amount due, takes ownership of it and display the barcode for the second split (change due).
  • The buyer’s app reads the barcode from the cash register and requests its ownership.
  • If any of the steps fail the transactions are rolled back and the payment is not successful.

Here are some examples of clients: