Internal Electronic Security Measures

Abstract

Security’s role has been articulated as managing the threats which pose a risk to the objectives of a particular enterprise or business (Black, Brassil & Hack, 2010). Thus, security is contextual in that it is driven by the threats which pose a risk within a specific protective setting. Therefore, the application of security measures is tailored to the needs and requirements of the facility, business, enterprise or institution to be secured. The security approach will be influenced by many factors. For example, the type of facility or material to be protected, the nature of the environment, a client's previous security experience, and any perceived threat. This report seeks to find out the underlying principles that govern its operation, its application, its limitations and how they may be overcome. The knock-on effects and unintended consequences of the use of the technology in the security domain will also be considered.

Introduction

Electronic Payment Instruments are usually governed, run and controlled by the Central Bank of a particular country. They work in such a way that there is no physical exchange of liquid or tangible money (Correa & Kumar, 2003); the Central Bank works electronically by making relevant adjustments in the virtual electronic accounts of a certain bank; for instance if Bank 1 and Bank 2 are carrying out a transaction between them, the Central Bank will reduce the amount in Bank 1's account by $100,000 and increase the amount of Bank 2's account by the same amount (Iyengar, 2007). This way, the funds will not pass through the hands of anyone unless either of the banks chooses to withdraw the funds as liquid money at some point; at the end of the whole transaction (Iyengar, 2007).

The Electronic Payment Instruments used by major banks or huge businesses apply the Real Time Gross Settlement systems that are normally denoted by RTGS in formal settings. The RTGS systems work in such a way that transfers between two transacting banks occur in real-time; the payment transaction does not need a waiting period for the transaction is settled down immediately after it is processed.

These systems are vastly used in foreign exchange markets with the most intense application being seen in Europe’s banking systems. Europe’s major application of this technology has been in the Trans-European Automated Real-time Gross Settlement Express Transfer System (TARGET) that is used in more than twenty-five countries in the EU (D'Atri & Italian Association for Information Systems Annual Conference, 2011).

Brief Description of the Functioning of the Technology

In most countries, payments that fall under the high-value or wholesale categories of payment are done using the Real Time Gross Settlement (RTGS) system (Bank of India 2013). They are done across all the banks and bank accounts held at the central bank (Suresh & Paul, 2010). The instructions for the transactions are done individually (Suresh & Paul, 2010). The individual doing the transaction; remitting the funds, is required to provide the amount meant to be remitted, their account number from which the funds are debited, (Suresh & Paul, 2010) the name and branch of the bank that the funds will be channeled to, the full official name of the person to whom the funds are being transferred, their account number, the person to receive information about the transaction from the sender’s side and IFSC code of the receiving branch (Electronic security technology roadmap, 2000).

When the systems work at their normal conditions, meaning that there is no network design or technical mishaps, the bank meant to receive the funds; the beneficiary bank is expected to receive the funds from the remitting bank without delays, also known as real-time. The receiving bank is then meant to credit the recipient or beneficiary's account, not more than two hours after they have received the funds transfer message (Ferrey & PennWell Corporation, 2000).

The remitting bank then receives a message from the reserve bank (the Central Bank’s electronic source) that the money has been credited to the receiving bank (Johnson, 1997). The remitting bank is then expected to advise the sender or remitting client that the money has been delivered to the receiving bank. Thanks to the whole of the confirmatory processes, the receiving bank, is very certain that the original instruction cannot be revoked hence ‘receiver's risk’ as it is technically referred to, is eliminated.

If the funds cannot be credited to the recipient for whatever reason, the receiving bank is forced to return the same amount of funds to the remitting bank within 2 hours (Itō & Folkerts-Landau, 1997). “Once the funds are received back by the remitting bank, the original debit entry in the customer's account is reversed hence the whole system ensures the safety of the client” (Itō & Folkerts-Landau, 1997). Most of the banks using this technology also have the resources for internet banking hence can provide tracking services for the whole transaction in the sense that they inform their clients about the success of the transaction immediately after the funds are received by the recipient’s bank account through a confirmation message by any real-time form of communication such as an e-mail or text message (WISM 2010, & Wang, 2010).

In the UK, CHAPS transfers and interbank payments in respect of CREST transactions are settled on an RTGS basis (Bank of England, 2013). CHAPS refers to the same-day electronic funds transfer service, offered by the CHAPS Clearing Company, owned by the commercial banks, that is used for large or high-value/wholesale payments and in special cases the lower value payments that are very critical, for example, the transaction for the purchase of a house. Individual CHAPS transaction instructions are routed through the SWIFT network to the main RTGS system and settled across the remitting and beneficial bank CHAPS banks’ settlement accounts.

Giving it a deeper eye, the message from the remitting bank account is kept or stored within SWIFT FIN Copy while the fully detailed copy of that message is sent to the bank for settlement. Once the transaction is settled in RTGS with finality; denoted by the remitting or sending bank’s account being debited and the beneficiary or receiving bank’s account being credited, a confirmation is returned to SWIFT and the full transaction information is then sent to the receiving bank that then processes the payment relevantly as required in its own payment systems.

For this process to be realized as a whole, there is a need for possession of liquid money (Quatermain, 2007). Every bank has its own system of providing liquidity to support the timely settlement of CHAPS payments in RTGS. Liquidity is mainly provided by holding balances on a settlement account also referred to as a ‘reserve account’. CREST refers to the UK’s securities settlement system which provides real-time cash against securities settlement for its members.

The CREST system handles securities transactions in a series of very high-frequency cycles through the day (Jilani, 2011); after each cycle the Bank’s RTGS system is advised of the debits and credits to be made to the CREST settlement banks’ accounts as a result of the settlement activity performed by CREST in that cycle. The whole relationship is reflected in the members’ cash memorandum accounts (CMAs) within CREST. This is compared to all the cash payments and receipts in relation to securities-related transactions. Banks set secured and unsecured credit caps to the CMAs of the CREST members that they represent, and which the CREST system operates in the settlement banks’ behalf through the CREST business day.

CREST settlement accounts in RTGS reflect zero balances overnight; debit against credit is balanced. Before any transaction is done in a new working day, banks transfer funds to their CREST settlement accounts. During the day, banks can add to or reduce the balance on their CREST settlement accounts. At the end of the CREST day, balances are automatically swept back up to the principal settlement/reserves account. As with CHAPS transfers, the Bank supports the real-time settlement process in CREST through the provision of intraday liquidity to the CREST settlement banks; and again this is provided via an intraday repo carried out on the Bank’s behalf by the CREST system.

In the RTGS system, the processor is the host; it is the home to all the details of the accounts held in the system and it is the one that coordinates all the postings made to these accounts or on behalf of the accounts. It is made to run on fault-tolerant computers to make sure that the RTGS system runs uninterrupted and in a smooth way. The main processor is tied to hardware and software processors at the prime site are duplicated in a remote standby site and changes to the prime site database are copied automatically to the standby site.

The same principle is used in the running of the system control; it is run from two sites that are separated. The RTGS processor has a Central Scheduler (CS) through which all CHAPS settlement instructions have to go through before the actual settlement is done. The CS is also used to control the frequency and pattern with which the CHAPS payment instructions move to the settlement section of the system. Most banks have adopted a strategy in which a third remote site; remote from the prime and standby site, is attached to the main RTGS. Others work with SWIFT; financial messaging software that runs remotely and enables account holders to have access to the Enquiry link based on SWIFT hence the ability to monitor activity on, receive information about their accounts and even transfer funds between accounts remotely via mobile phones.

Security Function

The RTGS systems have their own way of generating security to both the bank and the clients of the banks (Internet security, 2013). The system first eliminates the settlement risk by making sure the delay between the time of payment and the time of processing and settlement is reduced (Watson, 2007). This can be monitored in terms of the messages sent across the system denoting when the payment was done, and when the recipient of the funds received the funds. Consequent calculations are done by the system to ensure that the time between these two activities is as short as possible compared to the number of instructions the system receives per unit time. These save the client in terms of system fraud since the time the instructions take to be processed is too short for any theft to be done. It also ensures the bank does not have high liability levels in terms of debts.

Another underlying problem of such systems is the problem of liquidity (Quartermain, 2007). The systems have, however, been coded to improve the liquidity by providing clients with intraday credit that reduces the rate of risk to the client in the sense that, in case the bank is declared bankrupt, it is the bank that will suffer the risk and not the client. Previously, the clients were the ones subjected to this risk since most microfinance institutions and banks used to shut down without redeeming their clients’ funds when they were declared bankrupt.

Still on the problem of the risk created by intraday credit, two different approaches are used to control settlement risk. Most systems need the details for collateral to be fed into them for the intraday credit to be accredited to that particular account. This ensures the bank has security in terms of the risk involved with the credit while still providing liquidity to the bank. The designers of TARGET came up with a way of solving this problem (Pearson, 2007). They realized that some of the liquidity needs could be met with required reserves, but more was needed. The solution that was adopted allows system participants to borrow intraday funds at a zero interest rate.

TARGET is also seen to have long hours of operation. Generally, it starts its operations at 7:00 and terminates the operations at 18:00 ECB time. However, domestic systems are allowed to start their operations earlier, but only for domestic transactions (Pearson, 2007). All operations that involve the Euro as a currency and all external transactions are terminated by the systems exactly one hour before the systems shut down (Tanai, & Liebenau, 2009). The harmonization allows for a huge time between TARGET and the payment systems of the major financial centers hence assisting credit institutions and the different central banks worldwide to limit the cross-currency settlement risk (Tanai, & Liebenau, 2009). The common time of shutdown can be thought of as a way of obviating the risk of substantial payments being done outside the common operating hours hence prevents instances of “regional”/segmented movements in rates of interest that affects the conduct of the single monetary policy, which is aimed at achieving a constant level of interest rates in all areas under the euro currency.

The systems are also coded to ensure that the authentication information fed into the database is corresponding to those of the client registered under the account (Fair & Chalk, 2006). The full official names, the account numbers, address, date of birth and so on help the system in recognizing the particular file in which the transactions are being carried out. The systems are also seen to adopt the use SWIFT and other solid SSL and hence offer an adequate protection of the clients’ confidential information while still ensuring there is adequate protection from hackers and mimicked source websites that are made to get personal information from cardholders (Shroff, 2008). The SSL servers are identifiable to the clients since they are constantly being reminded by the system that is coded to automatically send such a message after a specific period of time, of the fraudulent people who create fake source websites to extort information from them (Shroff, 2008).

The system is also coded in such a way that it generates a new number per transaction to help the system in tracking all the transactions as separate entities (Nakajima, 2011). After the transaction is complete, the system automatically renders the number as unavailable hence no two transactions can have the same transaction ID (Ossolinski & Zurawski, 2010). This enables the system to trace the transactions within milliseconds in the case of verification or in the case where a question is raised about the transaction; for example when the funds have not reflected on the other side (International Conference on Information Technology Convergence and Services & Park, 2012).

A huge amount of the resources in the system have been dedicated towards the confidentiality of the client, the transaction details vital information like the amount being transferred and so on. The information is always kept confidential even in transit (Dally, & Riley, 1965). The data stored in the bank's database concerning the clients are also kept under strict confidentiality, and the access can only be granted under the orders of the client; (Gallagher, Gauntlett & Sunner, 2012) after they have provided information without which the same cannot be viewed. The bank knows of the amount and recipient only but is not aware of the payment details except that the payment has been made at a particular time to a particular person and the recipient only knows about the payment details but isn’t aware of other transaction details.

All these confidentiality preservation methods have been put in place to ensure neither of the parties involved knows more than they should for the smooth operation of the system (International Business Publications, 2011). In some cases, the client is also meant to prove that proof that they know the recipient, or they have a legal reason to transact with them especially during national crises to avoid acts of terror and maintain national security (Alexander, Dhumale & Eatwell, 2006) and (South Asian Society of Criminology et al 2011). The system also requires that the client confirms that they have approved the transaction to make sure the bank has tangible reference points when it comes to controversial cases; which haven’t been recorded yet (Jahankhani, 2010).

Conclusion

For many security programs, reliability and effectiveness are paramount. In addition, according to Likar, “only a strong human component can make a security system capable of responding to a human threat that can react in several ways to a fixed, technology-based security system” (Likar, 2011). For security systems to function effectively, the components, which make up these elements, must be configured and integrated into a complex engineering system. The technology used in Electronic Payment Instruments (EPIs) is one good example. This system is a dynamic and operational system of interconnected networks, with high governance by laws, regulations, and standards, which interconnects several bank accounts and provides the ability for exchange in monetary form using deposits placed in banks. It refers to the infrastructure (inclusive of all the institutions, technical tools, regulations, procedures, and standards involved in the exchange) set up with the aim of aiding in the transfer of money between two parties while eliminating mutual obligations. The efficiency of the technology, especially in terms of security, will largely affect its efficiency and all the risks associated with its use.

(Reference list omitted for preview. Available via download)