Server Side

The server side implementation of TDNSYS is very simple. It is similar to other Federal Reserve’s electronic system like Fedwire and its private sector competitor CHIPS, with the difference that is does not have accounts for handling money transfers and there is no processing required for a netting engine. The security and the possibility of penetration of TDNSYS should be identical to Fedwire.

I could not find any information on the Web about Fedwire, SWIFT or CHIPS being compromised due to technology problems. It is possible, like with any financial system, to use them in a fraudulent way. This may happen when there is a breach in security at one of the customers of these systems, most of the time by insiders.

An interesting example is one of the largest cyber-heists in history when hackers stole $81m from a Bangladesh Bank account at the New York Fed. Capitalizing on weaknesses in the security of the Bangladesh central bank, including the possible involvement of some of its employees, the perpetrators managed to compromise Bangladesh Bank's computer network, observe how transfers are done, and gain access to the bank's credentials for payment transfers.

TDNSYS is balances against the reserve accounts of member banks. Every time a TDN is issued or redeemed the reserve accounts are debited or credited as appropriate. This makes it easier to detect any, even though very unlikely, inconsistencies in the system.

In order to prevent fraud the Central Bank may request a digital certificate (issued by the Central Bank) when a transaction is initiated on a TDN with a value above a previously set threshold or when there are frequent transaction originating from a client. Central Bank issues TDN to banks and merchants accepting TDN. The financial institution and merchants will always be required to record their digital certificate when initiating TDN transactions.

TDNSYS also records all the Internet traffic trances related to a transaction and all the TDNs involved in the transaction. For example when a TDN is split, the initial TND and the two spits are recorded. This makes it possible to 'chain' transactions.

As mentioned above, due to some security problems at a member bank it is possible to have a TDN fraudulently issued to the bank. Even though the fraud occurred at the bank TDNSYS is used to investigate this fraud and the TDN stolen may be recovered

When a fraud is investigated the TDNs involved in the fraud will be blocked. If a transaction is initiated for any of these TDNs the transaction originator is informed that the TDN is under investigation and instructed to contact the investigative authority.

Let’s take a look of the following example:

• Due to a security breach a TDN is requested from the Central Bank.
• The person responsible for the fraud has access now to the TDN Signature.
• The bank discovers the fraud.
• An investigation case is opened by the Central Bank in the TDNSYS case management system
• If the status of the TDN is Active it means that the perpetrator did not use the TDN. The investigative authority changes the status to Canceled and the bank’s reserve account is debited for the TDN's dollar value. This reverse transaction is actually a redeem transaction.
• If the status of the TDN is Canceled it means that the TDN was split, consolidated or the TDN redeemed and changed.
In this situation it is possible to reconstruct a tree structure of all the TDNs cascading from the fraudulent TDN. Each leave in the tree can be traced back to the fraudulent TDN through a chain of transaction. Using this tree and all the information recorded for the nodes of the tree the investigative authority may be able to recover the TDNs and possible identify the perpetrator.

The usual criminal investigative techniques are also employed in solving and preventing TDN fraud.

Client Side

Because TDNs are very similar to paper money the prevention of lost or theft is the responsibility of the owner. All the rules for digital data security and privacy apply to TDNs. Transactions must be performed only with trusted parties especially when using the Internet. When using credit cards the credit card company may reimburse the card holder for unauthorized use. This is not the case with TDNs.

A fraud may occur when a TDN is compromised. A TDN is considered compromised if the TDN Signature is in the possession of more than one entity. It is impossible know if a TDN is compromised until a transaction is perform on that TDN. If the legal holder of the TDN performs the transaction (except validation) the fact that was compromised is obviously irrelevant. If however a fraudulent holder of the TDN uses it then the legal holder will no longer be able to use it. He/she may request an investigation to identify the fraudulent use of the TDN.

There may be more than one owner of a TDN when the parties involved in a transaction trust each other and the new TDN holder does not request ownership of the TDN. Theoretically the TDN is considered compromised but in this situation it is less likely a fraudulent transaction will be performed on that TDN. The new owner of the TDN assumes that the previous owner was not unknowingly in the possession of an already compromised TDN.

The party receiving a TDN has better means of protection against fraud then the sender. The TDN can be validated and the ownership transferred before the transaction is accepted. This assumes that the application or website used to perform these operations is legitimate. This is an issue only for transactions that occur infrequently, using fraudulent or compromised software. Merchants have very safe software/hardware systems. The unauthorized payments so frequent with credit cards do not a happen with TDNs.

Merchants must take measures to prevent employee theft. As it happens with cash employers may have access to TDNs. The theft is notice only when the stolen TND is involved in a transaction. Most of the systems will allow access to the TDNs only to a limited number of employees. . The best protection of against this fraud is depositing the TDNs into the merchant’s bank account immediately after they are received.

Merchants may accept TDN based debit or credit cards. In case of fraud the same rules as for any other debit/credit cards apply.

Banks may be able to recover TDNs lost by their customers. If for example a customer withdrew a TDN from his/her bank account and lose it a bank employee can identify the Signature of the TDN in question and if the status is still ' Active ' cancel it and issue a new one to the customer.

TDN based credit and debit cards have the same vulnerabilities as any other cards. If lost or stolen they can be fraudulently used if the PIN is also compromised. Card skimmers are ineffective when TDN smart cards are used for payments or at ATMs. There are no accounts to be stolen and the traffic between the card and the terminal is always encrypted.

Next

Prev