Goals for the Ultimate Payment and Settlement System

 source : RBI WEBSITE

Goals for the Ultimate Payment and Settlement System

 

“Anyone can make payments to whomsoever one likes, whenever one likes, in whatever type of currency one likes, at the cost of a few cents per transaction. There are no settlement delays or mountains of paperwork and value is received instantaneously. There are no distinctions in costs or delays between a domestic and a foreign currency transaction. Interest is computed real-time rather than on a "settlement day", a relic from the ancient times, when accounting was done manually. Finally, privacy and security are guaranteed.”

 

Chapter I

 

What are Payment Systems?

 

Payment Systems encompass a set of instruments and means generally acceptable in making payments, the institutional and organizational framework governing such payments and the operating procedures and communications network used to initiate and transmit payment information from payer to payee and to settle payments.

Payment system facilitates the exchange of goods and services between economic agents using an accepted medium of exchange. A modern payment system typically has a range of specialized subsystems developed to serve particular sets of customers; some of these clear and settle small payments, some large payments, while some cover both large and retail settlements.

 

The Core Principles for Systemically Important Payment Systems, outlined by the Committee on Payment and Settlement Systems of the Bank for International Settlements, Basle, define payment systems as “a set of instruments, procedures and rules for the transfer of funds among system participants”. The most significant payment systems, which the Report refers to as Significantly Important Payment Systems(SIPS), are a major channel by which shocks can be transmitted across domestic and international financial systems and markets.

 

As per our Payment System Bill, 2002, a ‘payment system’ means “a system that enables payment to be effected between a payer and a beneficiary and includes clearing, settlement or payment service”.

 

Why are they required and their Importance?

 

The Payment System has importance for the functioning and integration of financial markets. It influences the speed, financial risk, reliability and cost of domestic and international transactions. As a consequence, it can, among others, act as a conduit through which financial and non financial firms and other agents affect overall financial system stability, with a potential for domestic and cross border spill over effects. The payment system also affects the transmission process in monetary management, the pace of financial deepening and the efficiency of financial intermediation.

Payment system operates on the following generally accepted service standards.

 

“Anyone can make payments to whomsoever one likes, whenever one likes, in whatever type of currency one likes, at the cost of a few cents per transaction. There are no settlement delays or mountains of paperwork and value is received instantaneously. There are no distinctions in costs or delays between a domestic and a foreign currency transaction. Interest is computed real-time rather than on a "settlement day", a relic from the ancient times, when accounting was done manually. Finally, privacy and security are guaranteed.”

 

 The contrast with what is happening in reality is of course glaring, particularly in terms of delays and costs. The current payment system involves basically the same method to transfer value as it did 25 years ago, with parts of it dating back well into the 19th century. Despite the huge changes in the economy and available technologies, it takes almost as long to clear an ordinary payment to-day as it did then. Even in the wholesale markets for foreign exchange and money market contracts, "spot" transactions mean two-business days. This convention made sense, when book-keeping was done manually.

 

Similarly, all debts today are conventionally settled on a "settlement day" and interest is invariably computed to accrue on a daily basis. Why would it not be possible to operate in real-time, to reflect the difference of a deposit arriving at 10 am instead of 4 pm? By doing so, the delay between the time when the payment is made and that value is received would simply disappear. Notice that some evolution in this direction has already started to happen at least for the large transactions. For instance, in the UK, large transactions have been settled and cleared in real time via the CHAPS payment system since 1996. Although originally intended only for multi-million pound sterling transactions, and not withstanding substantial cost markups, one third of these payments are for less than GB£10,000, and two-thirds for less than GB£100,000.

 

Private individuals (for house purchases or other personal financial transactions) now initiate more than a quarter of all CHAPS transactions. The main reason people are willing to pay the high transaction fee, is the real time credit feature, and the banking system has clearly demonstrated that technology can provide this level of service when they want to. Similarly, several of the major international banks operate today state-of-the-art payment and world-wide cash management systems for their larger corporate clients. So, the payment world seems to be one with two means of transport: Ferraris for some selected clients and donkeys for everybody else, with not much in between. But the reason for those antiquated delays should also be obvious, as the benefits of the "float" generated in the process accrues to the main suppliers of the payment services. Speed is however, only part of the issue. The other important one is costs.

 

In essence, the payment systems are required for the following purposes:

 

1. For protecting key existing assets of the banking system:

 

A bank’s most important asset in an information age, a trusted brand name, would be protected and enhanced in such a strategy.

 

Another key asset is privileged customer relationship. The fact is that the vast majority of consumer current accounts are now with banks, and most new payment systems will have to – at least initially – debit funds from consumer’s existing bank accounts. By playing a leadership role in payment systems, the banking system would build on this strength to keep the new pattern of cash flows within the banking system. The alternative is that – just as already happened in savings accounts migrating to financial service companies – there will be a migration of current account deposits towards the new service providers.

 

2. For strengthening the customer base:

Banks in many countries are conducting expensive public relations campaigns to try to broaden their customer base. For example, aiming for the younger generation to open their first bank accounts. Most kids don’t have a bank account, but almost all have a cell-phone and use it extensively. Where do you think their loyalty will go when their phone company provides electronic payment services while the banks are still pushing them to open a checking account? There is also a growing political awareness of a technological underclass, people who are effectively excluded from the world of fast and cheap payments, and that will therefore be excluded from much of the economic activity in the world. Some potential payment systems providers are talking about a radical solution to this economic exclusion problem: that every member of society has the automatic right to an account on their system. Banks in their current expensive legacy framework would not be able or willing to match such an offer. Where does that leave them?

 

3: For Reducing existing costs and generating new income:

 

This problem can only be solved in one way: by the banks replacing their legacy systems with more up-to-date ones. The more there is a delay in realizing the importance of this problem, and the urgency of this solution, the more vulnerable the banks’ position in payment systems will become. By taking the initiative on designing internationally compatible, open-system, platform-independent payment standards, they would keep the full advantage of their existing client base, while benefiting from the new more efficient, low-cost service capabilities. They would also be able to ensure that their own transition from the old to the new standards can be performed cheaply, and on their own timing. This would not be the case if other organizations end up playing the role of new standard designers and implementers. Taking the initiative of reforming payment systems would not only structurally reduce a bank’s operating costs, but also generate new revenues by strengthening its role in electronic commerce beyond simple clearing. For example, authentication will become an important and high-value function in future fully-electronic-open-system payment systems. The initiative by a group of major financial institutions to create Identrus, a global electronic authentication service, is proof that there is a growing awareness about additional income from such new services.

 

Such new incomes may not replace lost ones in the immediate future. But the benefits of the status quo are only going to remain available in short-term, while all the advantages are valid in long-term. Another relevant dimension: most of the investments in the legacy systems are sunk costs, while the incomes are new and unencumbered. The ultimate trade-off will have to be made by each banker’s own cost-benefit analysis.

 

International Standards on Payment Systems :

 

The Committee on Payment and Settlement Systems (CPSS) of the central banks of the Group of Ten countries is contributing to this process through its work on developing core principles for systemically important payment systems. The CPSS established a Task Force on Payment System Principles and Practices in May, 1998 to consider what principles should govern the design and operation of payment systems in all countries. The Committee realizes that the Payment Systems are not fault-free and can go wrong and the core principles, developed and suggested, have factored in these weaknesses and suggested the principles for removing these inherent weaknesses.

 

Payment systems are the means by which funds are transferred between banks, and the most significant payment systems, are a major channel by which shocks can be transmitted across domestic and international financial systems and markets. Robust payment systems are, therefore, a key requirement for maintaining and promoting financial stability. Over the past a few years, a broad international consensus has developed on the need to strengthen payment systems by promoting internationally accepted standards and practices for their design and operation.

 

The core principles are intended for use as universal guidelines to encourage the design and operation of safer and more efficient systemically important payment systems worldwide.

 

The principles apply to systemically important payment systems, whether they involve a credit or debit mechanism and whether they operate electronically or involve paper-based instruments. In practice, however, for a system that uses paper-based debit instruments (e.g. cheques), there are particular difficulties involved in satisfying some of the principles. In countries, where an existing systemically important payment system uses cheques, it may be necessary to give careful consideration to the other options available.

 

Payment systems can be subject to a range of risks, including:

 

Credit risk: the risk that a party within the system will be unable fully to meet its financial obligations within the system currently or at any time in the future;

Liquidity risk: the risk that a party within the system will have insufficient funds to meet financial obligations within the system, as and when expected, although it may be able to do so at some time in the future;

Legal risk: the risk that a poor legal framework or legal uncertainties will cause or exacerbate credit or liquidity risks;

Operational risk: the risk that operational factors such as technical malfunctions or operational mistakes will cause or exacerbate credit or liquidity risks; and

Systemic risk: in the context of payment systems this is the risk that the inability of one of the participants to meet its obligations, or a disruption in the system itself, could result in the inability of other system participants or of financial institutions in other parts of the financial system to meet their obligations, as they become due. Such a failure could cause widespread liquidity or credit problems and, as a result, could threaten the stability of the system or of financial markets.

The core principles apply to payment systems which could trigger or transmit systemic disruptions in the financial area because of the size or nature of individual payments, which they handle or because of the aggregate value of the payments processed. A payment system does not necessarily handle only high-value payments; the term can include a system which handles payments of various values, but which has the capacity to trigger or transmit systemic disruption by virtue of certain segments of its traffic. In practice the boundary between payment systems, which are systemically important and those which are not will not always be clear-cut and the Central Bank will need to consider carefully where that boundary should be drawn. The principles may also be useful in assessing and understanding the characteristics of systems, which pose

relatively little systemic risk and it may be desirable for such systems to comply with some or all of the principles.

 

Systemically important payment systems may be owned and operated by the Central Banks or by private sector institutions. There are also cases where they are owned and operated jointly by public and private agencies. The core principles are intended to be relevant to all institutional and ownership structures. They address primarily the design and operation of payment systems, but are intended also to influence the actions of participants and of agencies that supervise participants. The role and responsibilities of the operator and the participants should be clearly defined and understood. The central bank has key responsibilities in applying these principles.

 

Although the principles are expressed in terms of payment systems in a single country, they are equally applicable, where the payment system arrangements extend over a broader economic area, such as where a single payment system or a collection of interconnected payments systems cover a region broader than a country. The principles also apply to cross-border or multi-currency payment systems.

 

The core principles for payment system :

 

I. The system should have a well-founded legal basis under all relevant jurisdictions.

 

The rules and procedures of a system should be enforceable and their consequences predictable. A system, which is not legally robust or in which the legal issues are poorly understood, could endanger its participants. Poor understanding can give participants a false sense of security, leading them, for example, to underestimate their credit or liquidity exposures. The jurisdiction under whose law the system’s rules and procedures are to be interpreted should be specified clearly. In most cases, the most important legal environment will be the domestic one, although, in particular where the system involves cross-border elements such as foreign bank participation or the use of multiple currencies, it will also be necessary to consider whether there are any material legal risks stemming from other relevant jurisdictions.

 

A sound legal basis is fundamental to risk management. Careful attention should be given to the:

 

·         completeness and reliability of framework legislation; 

·         enforceability of laws and of contracts in all relevant circumstances; 

·         clarity of timing of final settlement especially when there is an insolvency;

·         legal recognition of netting arrangements;

·         existence of any zero hour or similar rules; 

·         enforceability of security interests provided under collateral arrangements and of any relevant repo agreements;

·         a legal framework that would support electronic processing of payments;

·         relevant provisions of banking and central banking law;

·         Relevance of laws outside the domestic jurisdiction.

 

II. The system’s rules and procedures should enable participants to have a clear understanding of the system’s impact on each of the financial risks they incur through participation in it.

Participants, the system operator, and other involved parties - in some cases including customers - should understand clearly the financial risks in the system and where they are borne. An important determinant of where the risks are borne will be the rules and procedures of the system. These should define clearly the rights and obligations of all the parties involved and all such parties should be provided with up-to-date explanatory material. In particular, the relationship between the system rules and the other components of the legal environment should be clearly understood and explained. In addition, key rules relating to financial risks should be made publicly available.

Participants need to understand the financial risks they bear. Operators should, therefore, have rules and procedures that:

 

·         are clear, comprehensive and up-to-date;

·         explain the system design, its timetable and risk management procedures;

·         explain the system’s legal basis and roles of the parties; 

·         are readily available;

·         explain where there is discretion and how it is exercised;

·         set out decision and notification procedures and timetables for handling abnormal situations.

III. The system should have clearly defined procedures for the management of credit risks and liquidity risks, which specify the respective responsibilities of the system operator and the participants and which provide appropriate incentives to manage and contain those risks.

 

The rules and procedures of a systemically important payment system are not only the basis for establishing where credit and liquidity risks are borne within the system, but also, for allocating responsibilities for risk management and risk containment. They are, therefore, an important mechanism for addressing the financial risks, which can arise in payment systems. Private sector parties, in particular, could have inadequate incentives to limit or manage these risks. A system’s rules and procedures should, therefore, ensure that all parties have both the incentives and the capabilities to manage and contain each of the risks they bear and that limits are placed on the maximum level of credit exposure that can be produced by each participant. Limits on credit exposure are likely to be particularly relevant in systems involving netting mechanisms.

The effective management of financial risks is at the heart of designing safe payment systems. The appropriate tools and incentives depend on the type of system design, but techniques include:

 

Tools for managing credit risks

·         Using system designs in which credit risk between participants does not arise (e.g. in real-time gross settlement system);

·         Access criteria (but the system needs also to comply with Core Principle IX);

·         Credit limits (bilateral or multilateral) to cap exposures;

·         Loss-sharing arrangements and/or “defaulter pays” arrangements.

Tools for managing liquidity risks

·         Management of payment queues;

·         Provision of intraday credit (which means credit risk issues for the lender, e.g. the Central Bank); 

·         Throughput guidelines;  Position (receiver or sender) limits;

·         Tools described under Core Principle V for systems with deferred net settlement.

General tools

·         Information systems to support the tools for managing credit and liquidity risks;

·         Clear, full and timely (ideally real-time) financial information to participants; 

·         Timely monitoring by the system operator.

·          

Incentives to manage these risks can come from:

·         Formula for loss-sharing – for example, if it reflects the scale/nature of controllable positions with the failed institution; 

·         Pricing.

 

IV. The system should provide prompt final settlement on the day of value, preferably during the day and at a minimum at the end of the day.

 

This principle relates to daily settlement in normal circumstances. Between the time when payments are accepted for settlement by the payment system (including satisfaction of any relevant risk management tests, such as the application of limits on exposures or availability of liquidity) and the time when final settlement actually occurs, participants may still face credit and liquidity risks. These risks are exacerbated if they extend overnight, in part, because a likely time for the relevant authorities to close insolvent institutions is between business days. Prompt final settlement helps to reduce these risks. As a minimum standard, final settlement should occur at the end of the day of value.

 

Promptness of final settlement on the day of value entails:

 

·         clarity in the system rules and procedures that a payment accepted by the system for settlement cannot be removed from the settlement process;

·         a clearly defined and legally effective moment of final settlement;

·         ensuring that the interval between the system’s acceptance of a payment and the payment’s final settlement at least never lasts overnight and preferably is much shorter; 

·         Ensuring that operating hours and the settlement processes are strictly enforced.

V. A system in which multilateral netting takes place should, at a minimum, be capable of ensuring the timely completion of daily settlements in the event of an inability to settle by the participant with the largest single settlement obligation.

 

Multilateral netting systems with deferred settlement face the risk that a participant will not be able to meet its settlement obligations, raising the possibility that other participants will face unexpected credit and liquidity pressures at the time of settlement. Such systems, therefore, need strong controls to address this settlement risk.

 

Lamfalussy Standard IV specified that, at a minimum, a netting system must be able to withstand the failure of the largest single net debtor to the system. This approach underlies the present arrangements in many payment systems that settle on a net basis for limiting credit and liquidity risk, and for ensuring access to liquidity in adverse circumstances. But this approach is developing. Systems which satisfy only this minimum standard are still exposed to the financial risks of the failure of more than one institution during the same business day. The circumstances in which one large net debtor is unable to meet its settlement obligations to the system may well be those in which other institutions are also under liquidity pressure. Best international practice now is, therefore, for such systems to be able to withstand the default of more than the one participant with the largest single settlement obligation. Careful consideration should be given to this approach and its implications should be evaluated taking into account the benefits of reduced settlement risk and any other consequences such as for the management of liquidity. In addition, alternative system designs (such as RTGS or hybrid systems) are increasingly being adopted to reduce or eliminate settlement risk. System that combines multilateral net settlement with deferral of settlement needs to be protected against liquidity risk arising from an inability to settle on the part of one or more participants.

·         This can be achieved by ensuring that additional financial resources are available to meet this contingency. These usually involve a combination of the following:

–               A pool of collateral (cash or securities), appropriately valued;

–               committed lines of credit.

 

·         The amount of such additional resources needs to be determined in relation to:

 

–        Maximum individual settlement obligation;

–        Whether the system meets or exceeds the minimum standard (i.e. whether the system is designed to withstand an inability to settle by the participant with the largest single settlement obligation or to withstand a more widespread inability to settle).

·         Alternatively, the need to control liquidity risk in this context can be avoided by the use of an alternative system design (e.g. RTGS or some types of hybrid design) that does not give rise to the concerns addressed by Core Principle V.

 

VI. Assets used for settlement should preferably be a claim on the central bank; where other assets are used, they should carry little or no credit risk.

 

Most systems involve the transfer of an asset among system participants to settle payment obligations. The most common and preferable form of such an asset is an account balance at the central bank, representing a claim on the central bank. There are, however, examples of other forms of settlement asset, representing claims on other supervised institutions. As all participants in the system must accept the asset, the system’s safety depends in part on whether the asset leaves the holder with significant credit risk. If there were more than a negligible risk that the issuer of the asset could fail, the system could face a crisis of confidence, which would create systemic risk. Balances at the central bank are generally the most satisfactory asset used for settlement, because of the lack of credit risk for the holder, and they are typically used in systemically important payment systems. If settlement is completed using other assets, such as claims on a commercial bank, those assets must pose little credit risk. In some payment systems minimal use is made of a transferable asset. For example, they may settle by offsetting one claim against another. This can be consistent with Principle VI provided that there is no inconsistency with the other principles, particularly with Principle I, which requires the legal basis for the offset process to be sound.

 

The most satisfactory settlement asset for systemically important payment systems is a claim on the central bank issuing the relevant currency. If other assets are used, considerations relevant to whether Core Principle VI is met are:

 

·         the creditworthiness of the issuer of the settlement asset; 

·         how readily the asset can be transferred into other assets; 

·         size and duration of involuntary exposures to the issuer; 

·         Risk controls, if any.

 

VII. The system should ensure a high degree of security and operational reliability and should have contingency arrangements for timely completion of daily processing.

 

Market participants rely on payment systems for settling their financial market transactions. To ensure the accuracy and integrity of these transactions, the system should incorporate commercially recognized standards of security appropriate to the transaction values involved. These standards rise over time with advances in technology. To ensure completion of daily processing, the system should maintain a high degree of operational resilience. This is not just a matter of having reliable technology and adequate back up of all hardware, software and network facilities. It is also necessary to have effective business procedures and well-trained and competent personnel who can operate the system safely and efficiently and ensure that the correct procedures are followed. This, together with good technology, will, for example, help to ensure that payments are correctly and quickly processed and that risk management procedures, such as limits, are observed. The degree of security and reliability required for providing adequate safety and efficiency depends on the degree of systemic importance of the system, as well as any other relevant factors, such as the availability of alternative arrangements for making payments in contingency situations.

 

The designers and operators of payment systems should consider the following issues in relation to security and operational reliability :

 

General

·         The system should meet the security policies and operational service levels agreed by the system operator and participants, and relevant legal constraints, system rules, risk management procedures, business requirements, or international, national or industry-level standards.

·         The system’s security and operational reliability depend on both central system and participants components; the participants have responsibilities for security and operational reliability. The system should be formally monitored to ensure the policies and service levels are being met.

·         Security policies and operational service levels should change over time, in response to market and technological developments; system should be designed and operated to meet such developments.

·         The system requires adequate numbers of well-trained, competent and trustworthy personnel to operate it safely and efficiently in both normal and abnormal situations.

Security

·         Security objectives and policies should be established during the design of the system, and reviewed periodically. They should be appropriate to the payment system, recognising its particular architecture and ownership. 

·         System security should conform to commercially reasonable standards, for example, for confidentiality, integrity, authentication, non-repudiability, availability and auditability. Security features should be tested regularly.

·         The system should be subject to regular security risk analyses. The system operator should pro-actively monitor technological advances to keep system’s security risk analysis up-to-date.

Operational reliability

·         Threats to operational reliability arise not just from the failure of central system and participant components, but also from failures of infrastructure services and natural disasters.

·         The system requires comprehensive, rigorous and well-documented operational and technical procedures.

·         Changes to the system should be properly documented, authorised, controlled, tested and subject to quality assurance.

·         The system should be designed with sufficient capacity, which should be monitored and upgraded in advance of business changes.

 

Business continuity

·         The system operator should carry out a formal business continuity planning exercise. Simplicity and practicality should be key considerations when designing contingency arrangements.

·         Business continuity arrangements should be documented and regularly tested. They should include procedures for crisis management and information dissemination.

·         Business continuity arrangements could include: diversion of payments to another payment system; a second processing site; and/or a “minimum level service”.

 

VIII. The system should provide a means of making payments which is practical for its users and efficient for the economy.

 

Operators, users (that is participants, such as banks and their customers) and overseers of systems, all have an interest in the efficiency of a system. They want to avoid wasting resources and, other things being equal, would wish to use fewer resources. There will typically be a trade-off between minimising resource costs and other objectives, such as maximising safety. Within the need to meet these other objectives, the design of the system, including the technological choices made, should seek to economise on relevant resource costs by being practical in the specific circumstances of the system, and by taking account of its effects on the economy as a whole. The costs of providing payment services will depend on the quality of service and the features demanded by the users, and on the need for the system to meet the core principles limiting risk in the system. A system which is consistent with the demands of the markets it serves is likely to be more heavily used and so will spread more widely the risk-reducing benefits of satisfying the other principles and the costs of providing the services. Designers and operators of payment systems need to consider how to provide a given quality of service, in terms of functionality, safety and efficiency, at minimum resource cost. The relevant costs are not just those passed on to users through system charges, but those of the total resources used by the system and its users in providing the payments services. They will need, for example, to take into account any indirect costs to users, such as the costs of liquidity and collateral.

 

The availability of liquidity in a system can be an important element in its smooth operation. Recipients like to be paid in funds which are immediately reusable and so value the advantages of systems with intraday settlement. Senders, however, may face costs in raising liquidity to enable them to pay early in a system. Where systems have inadequate intraday liquidity mechanisms, they can face a risk of slow turnover or even gridlock (where participants are each waiting for the others to pay first). In the interests of efficiency, systems should provide participants with adequate incentives to pay promptly. For real-time systems the supply of intraday liquidity is particularly important. Relevant factors in its supply will include the depth of inter-bank money markets and the availability of any relevant collateral. With the benefits of smooth payment flows in mind, the central bank should consider whether and how to provide intraday liquidity to support a system’s daily functioning.

 

The technology and operating procedures used to provide payment services should be consistent with the types of services demanded by users, reflecting the stage of economic development of the markets served. The design of the payment system should therefore be appropriate for the country’s geography, its population distribution and its infrastructure (such as telecommunications, transportation and banking structure). A particular design or technological solution which is right for one country may not be right for another.

 

General

·         Define objectives (identifying risk and efficiency factors) 

·         Identify user needs and cons0raints

·         Identify system choices and benefits 

·         Determine social and private costs

·         Develop decision choices

Analytical framework

·         Identify efficiency requirements (or conversely identify inefficiencies) 

·         Identify safety requirements  Evaluate costs (social and private) 

·         Identify resources (social or private)

·         Determine practical constraints (technology, infrastructure) 

·         Define safety constraints (e.g. applying the Core Principles)

Methods

·         Cost-benefit or other structured analysis

·         Involvement of participants and/or users in discussions

·         Methodology for data collection and analysis

·         Identify data sources (archived data, economic data, samples or estimates)

IX. The system should have objective and publicly disclosed criteria for participation, which permit fair and open access.

 

(IX.1) Access criteria that encourage competition amongst participants promote efficient and low-cost payment services. This advantage, however, may need to be weighed against the need to protect systems and their participants from participation in the system by institutions that would expose them to excessive legal, financial or operational risks. Any restrictions on access should be objective and based on appropriate risk criteria. All access criteria should be stated explicitly and disclosed to interested parties.

 

(IX.2) The rules of the system should provide for clearly specified procedures for orderly withdrawal of a participant from the system, either at the participant’s request, or following a decision by the system operator that the participant should withdraw. A central bank’s actions in withdrawing access to payment system facilities, or to settlement account services, may also lead to the withdrawal of a participant from a payment system, but it may not be possible for a central bank to specify explicitly in advance all the circumstances in which it might act in this way.

 

Access criteria should encourage competition among participants, without compromising the system’s safety. Criteria that restrict access should be assessed for :

 

·         Justification in terms of safety;

·         Justification in terms of efficiency; 

·         Consideration should be given to adopting forms of risk management which have the least restrictive impact on competition that circumstances permit.

 

X. The system’s governance arrangements should be effective, accountable and transparent.

 

Payment system governance arrangements encompass the set of relationships between the payment system’s management and its governing body (such as a board of directors), its owners and its other stakeholders. These arrangements provide the structure through which the system’s overall objectives are set, how they are attained and how performance is monitored. Because systemically important payment systems have the potential to affect the wider financial and economic community, there is a particular need for effective, accountable and transparent governance, whether the system is owned and operated by the central bank or by the private sector.

 

Effective governance provides proper incentives for management to pursue objectives that are in the interests of the system, its participants and the public more generally. It also ensures that management has the appropriate tools and abilities to achieve the system’s objectives. Governance arrangements should provide accountability to owners (for example, to the shareholders of a private sector system) and, because of the system’s systemic importance, to the wider financial community, so that those served by the payment system can influence its overall objectives and performance. An essential aspect of achieving accountability is to ensure that governance arrangements are transparent, so that all affected parties have access to information about decisions affecting the system and how they are taken. The combination of effective, accountable and transparent governance provides a foundation for compliance with the core principles as a whole.

 

In contrast to many of the other Core Principles, it is difficult to advise on the appropriate structure of governance, because there are so many possible arrangements. It is, however, possible to suggest indicators that governance arrangements are effective, accountable and transparent. It is advisable for governance arrangements to be reviewed regularly against such indicators. The following is not an exhaustive list of indicators, nor does any one of these factors alone necessarily indicate whether the system complies with Core Principle X:

 

·         Relevant information on the system and its operations is readily available, complete and up-to-date;

·         Major decisions are made after consultation with all interested parties and due deliberation;

·         The high-level decision-making process is prompt and communicated clearly to the system users;

·         The system consistently attains projected financial results and can explain any differences from those plans;

·         The system delivers payment services that satisfy customer needs;

·         The system complies with the other nine Core Principles.

 

Chapter  II

 

Our Initiatives on Payment System

 

RBI has undertaken a number of initiatives in the field of Payment Systems. A summary of the initiatives is as follows:

v  RBI is trying to build an integrated market which will enhance the effectiveness of policies and for facilitating better functioning of markets  and will have characteristics such as absence of administrative restrictions,  especially on cross-border and cross-market transactions and informational barriers, risk-adjusted returns on assets. This will help in the growing market economy.

v  The Payment systems will widen the participant base, improve information base for all participants, create greater transparency and encourage good market practices, introduce efficient settlement mechanisms, rationalise tax structures, create better infrastructure to facilitate faster transactions and lower their costs.

v  The setting up of Real Time Gross Settlement System (RTGS) is also expected to lower transaction costs by speedier settlement, among other considerations.

v  Establishment of Negotiated Dealing System by RBI has facilitated both electronic bidding in auctions and dealing in Government securities and money market instruments. It will facilitate a shift from largely telephone-based trading to a completely screen-based on-line trading. Such electronic trading is expected to reduce information asymmetry in the markets and prevent the possibility of collusive trading that provides excess returns to some investors.

v  The Clearing Corporation of India Ltd. put in place has already started acting as a Central Counter Party for the Government Securities and recently the Forex Clearing was made operational.

v  RBI has set up the INFINET, as hybrid network of VSATs and leased lines, for providing the communication backbone for the financial transactions for the entire banking and financial sector.

v  Centralised Funds Management System has been put in place. The first phase of the CFMS allows the treasury managers to have an integrated view of the funds position across geographies.

v  Structured Financial Messaging System has been developed by IDRBT and RBI to standardise the message formats for various banking transactions including currency and government transactions.

v  PKI based superior security solution is being recommended for all the financial transactions for the banking and financial industry. IDRBT will be acting as the Certifying Authority (CA) for the sector and will be dealing with the due-diligence process for the requirements of the certification process.

 

Systemically Important Payment Systems in India

 

The Working Group on Systematically Important Payment Systems, set up by the RBI, has identified the following payment systems as systemically important  based on, inter-elia; whether the participants are banks or not, whether the settlement takes place in the books of Central bank or not, whether the individual value of payments is typically small or not, whether the transactions relate to financial markets or not, whether the failure of one or more participants has a cascading and contagious effect on other participants and other systems :

 

v  The Inter-bank Clearing System;The High Value Clearing System;

v  The Securities Clearing and Settlement System;The MICR Clearing System;

v  The Government Securities and Foreign Exchange Clearing Systems; and,The proposed Real Time Gross Settlement System.

 

Chapter III

 

RTGS Concepts and Working of the RTGS System

 

The Inter-bank payment systems handle large amounts of money. An estimate indicates that in the G-10 countries alone the turnover of the main systems is more than the equivalent of US$ 5 trillion each day. Many of these payments are for the settlement of financial market transactions between the banks themselves, such as Inter-bank loans or foreign exchange deals; other payments are made by banks on behalf of their customers.

 

In recent years, it has been increasingly realized that the way in which many of the systems traditionally worked exposed the participating banks to substantial  Inter-bank risks - resulting in the systemic risk that, if one bank were to fail for any reason, other banks in the system could fail as a consequence of these Inter-bank exposures. Because of these concerns, countries around the world have been taking action to make their payment systems more robust. One method of doing this, and one that has been adopted in an increasing number of cases, is to introduce an RTGS (Real Time Gross Settlement) system.

 

An RTGS payment system is one in which payment instructions between banks are processed and settled individually and continuously throughout the day.

This is in contrast to net settlement  systems (such as paper-based clearing houses and their more modern electronic equivalents), where payment instructions are processed ("cleared") throughout the day but Inter-bank settlement (i.e. the movement of the funds between the banks) takes place only afterwards, typically at the end of the day. The attraction of the RTGS systems is that payee banks and their customers receive funds with certainty, or so-called finality, during the day, enabling them to use the funds immediately without exposing themselves to risk.

 

A lag between the time at which information is made available to receiving banks and the time at which settlement takes place may have important risk implications in large-value funds transfer systems. Even in the RTGS environment, where both processing and final settlement are made in real-time, several circumstances can be identified in which the treatment of payment messages or the associated information could be a source of risk.

 

To initiate a funds transfer, the sending bank dispatches a payment message which is subsequently routed to the central bank and to the receiving bank as the system processes and settles the transfer. Arrangements for routing payment messages in the majority of RTGS systems are based on a so-called V-shaped message flow structure. In this structure the full message with all the information about the payment (including, for example, the details of the beneficiary) is initially passed to the central bank and is sent to the receiving bank only after the transfer has been settled by the central bank.

 

Some RTGS systems, and particularly those that use the S.W.I.F.T. network, apply an alternative structure, known as a Y-shaped structure. In this case, the payment message is transmitted by the sending bank to a central processor. The central processor takes a subset of information that is necessary for settlement from the original message and routes this core subset to the central bank (the original message being kept in the central processor). Upon receipt of the core subset, the central bank checks that the sending bank has sufficient covering funds on its account and informs the central processor of the status of the transfer, for instance, queued or settled. Once settled, the full message containing the confirmation of settlement is rebuilt by the central processor and sent to the receiving bank. The business information exchanged between the sending and receiving bank is, therefore, not known by the settlement agent.

 

A third structure (so far adopted only by CHAPS) is L-shaped structure, which is conceptually similar to a Y-shaped structure. The payment message dispatched by the sending bank is held at a system "gateway" attached to the sending bank's internal processing system and a subset of information contained in the original message (a settlement request) is sent to the central bank. If the sending bank has sufficient covering funds on its account, settlement is completed and the central bank sends back a confirmation message to the sending bank's gateway. Upon receipt of this confirmation (and only then), the original payment message is released automatically from the gateway of the sending bank and sent to the receiving bank.

 

These different structures reflect differences in both the network configuration of the system and the operational role of the central bank. In both the V and Y-shaped structures, all messages from the sending bank are routed first to a central entity (S.W.I.F.T., a central processor or the central bank itself) and, after settlement; all messages to the receiving bank are sent by that central entity. By contrast, there is no central entity for delivering messages in the L-shaped structure, where message routing is based on the bilateral exchange of information between banks, reflecting the decentralized architecture of the CHAPS system. In terms of its operational role in the system, the central bank is directly involved in both the settlement and processing of payment messages in the V-shaped structure, while in the Y and L-shaped structures the process of message routing can be handled by the network operator or the banks themselves, with the central bank only acting as the settlement agent.

 

These above three types of structure share the common feature that the receiving bank will receive the full payment message only after the transaction has been settled by the central bank. In these structures, therefore, the message flow structure per se cannot give rise to the possibility that the receiving bank will act upon unsettled payments.

 

Alternatively, RTGS systems could apply a T-shaped structure, in which the sending bank routes payment messages directly to the receiving bank (through the message carrier), with copies (made by the message carrier) sent simultaneously to the central bank. This means that the receiving bank will first receive the full, unsettled payment message immediately after the sending bank has dispatched it and will subsequently also receive a confirmation message from the central bank once settlement has taken place. The T-shaped structure has generally been viewed as being incompatible with the basic principle of RTGS that a funds transfer should be passed to a receiving bank, if and only if, it has been settled irrevocably and unconditionally by the central bank.

 

Reserve Bank of India has chosen Y – shaped structure to meet strategic objectives i.e. possibility to hive-off  the Inter-bank Funds Transfer Processor (IFTP), which strips and retains the customer-related information and forwards the payment and settlement particulars to the RTGS,  to an independent industry service provider.

 

Pros & Cons and comparison with other settlement systems

 

·         Operating Concept :

 

The distinction between Real Time Gross Settlement (RTGS) systems and deferred (or designated-time) net settlement systems (DNS) concerns the form and timing of settlement, not the way that payment messages are processed or transmitted. DNS systems can handle payment messages in real time but they settle in batches on a net basis at designated times, which could be during the operating day or, more typically, at the end of the day. RTGS systems, on the other hand, settle payments on a transaction-by-transaction basis as soon as they are accepted by the system.

 

·         Risk:

 

At the designated time, DNS systems settle multiple payments that have already been accepted by the system for settlement. This causes the system’s participants to be exposed to financial risks for the period during which settlement is deferred. If not sufficiently controlled, these risks can affect not only direct counterparties but also other participants, because one participant’s inability to settle could cause the positions of other participants to change, opening up the possibility that they too might fail to meet their altered obligations.

 

RTGS systems, however, do not create credit risk for the receiving participant because they settle each payment individually, as soon as it is accepted by the system for settlement. For any payments not accepted, liquidity risks remain, as well as the possibility of risks being shifted outside the system.

 

Intraday Liquidity Requirements:

 

RTGS systems can require relatively large amounts of intraday liquidity because participants need sufficient liquidity to cover their outgoing payments. Liquidity can come from various sources, including opening balances, or reserve balances at the central bank, incoming payments and intraday credit (which is usually provided by the central bank). Adequate liquidity, relative to the value and distribution of payments, makes a smooth flow of payments possible through such systems, helping to avoid delays to individual payments and minimising liquidity risks.

Cost of Intra-day liquidity

 

The cost of intraday liquidity depends on a number of variables, including the amount required, the opportunity cost of maintaining liquid balances, and the cost of intraday credit (e.g. collateral costs, overdraft charges).

In DNS systems, intraday liquidity is provided by the participants in the system, exposing them to credit and liquidity risks. Costs arise in introducing mechanisms for controlling these financial risks, for example, the costs of complying with the Core Principle V by establishing a collateral pool and obtaining committed lines of credit in order to ensure the timely completion of daily settlements in adverse circumstances.

 

Chapter IV

 

Proposed RTGS Solution in India-Salient Features

 

The RTGS Solution soon to be rolled out in the Indian financial environment incorporates the best international features and practices. All efforts have been made to learn from the fore-runners, while keeping in view the unique requirements of the financial system in our country.

 

The salient  features are given hereunder :

 

A. Strong Technological Support :

 

Technology has been the driving force for many payment system innovations in the recent past. Not surprisingly, the proposed RTGS solution aims at being a state-of-the-art solution with the use of the INFINET as the dedicated, secure communication backbone, SFMS as the secure messaging system and IBM’s S/390 mainframe system as the robust platform at the back-end for implementation. Quaestor, a product from the solution developer, Logica India, is proposed to be customised to serve as the front end for the solution, while MQ series is the “gluing” interface between the various components of the solution.

 

B. Y- message Flow Structure :

 

The solution provides for a single gateway interface (Participant Interface or PI) to the RTGS system for each participant. All Payment messages of the participant emanate from the PI. So do other messages e.g. enquiries etc.. Irrespective of their nature, messages emanating from the PI will do so in a secure fashion, which will ensure their confidentiality, integrity and non-repudiation. Again, all the messages will be received by the Inter-bank Funds Transfer Processor (IFTP) – a component of the RTGS system, which will act as a broker. The IFTP will safe-store the message and, in case of payment messages, construct a settlement message, containing only the data required for settlement by stripping-off the commercial/customer data and will forward the same to the Central RTGS System. The settlement message is processed by the Central System and the fate of the settlement message is advised to the IFTP. Based on the response received, IFTP enriches the message received from the RTGS system by adding back the corporate details and sends the settlement advice to both the originating and the beneficiary participant(s), in case of successful settlement or the failure advice to the originating participant, in case of failed settlement.

 

The advantage of this topology is that the beneficiary is notified only after the settlement has been successful and funds have been applied to its account.  It also enables the central RTGS processor to concentrate on what it does best i.e. settle transactions, while the other housekeeping tasks are taken care of by the IFTP.

 

C. Participant’s Dedicated Settlement Account for RTGS Transactions:

 

A single dedicated account, the RTGS Settlement Account for each participant for outward and inward RTGS payments, is provided by the solution, enabling easy monitoring, tracking and reconciliation of the transactions as well as more efficient liquidity management.

 

Each participant of the RTGS system will be required to open a dedicated settlement account for putting through its RTGS transactions. This account will be an intra-day account in the sense that it would be operational only during the duration of the RTGS day. The account would be funded at the start of the day (SOD) from a current account, the participant holds under the present dispensation at DAD, Mumbai. Balances in the RTGS Settlement account at the End of Day (EOD) of the RTGS day are swept back to the Participant’s current account and thereby zeroing the RTGS settlement account.

The system enables the participants to place standing instructions with DAD, Mumbai to fund their RTGS settlement account each morning. They can specify an actual amount or percentage of balance to be transferred to the RTGS settlement account every day at SOD. Participants can also specify a minimum threshold value, which must be maintained in their current account while funding their RTGS settlement account.

 

The system also provides a facility to fund the RTGS settlement account during the day from the participants’ current accounts by the use of Own Account Transfers (see below).

 

D. FIFO processing/Transaction Priority :

 

Payment transactions emanating from a participant’s payment Systems gateway are processed by the RTGS system strictly in First-In-First-Out or FIFO basis. However, to enable the participants to take care of urgent or time critical payments and to enable more effective funds management, the system allows the participants to assign priorities to their payment messages and  thereby, enabling a particular transaction to be processed before another transaction, which was submitted earlier to the RTGS system. Within payment messages having the same priority, however, the transactions will be processed on FIFO basis.

 

E. Payment Queues :

 

Payment transactions, emanating from a participant are ordinarily expected to be settled immediately after it is received. This is the essence of a real time system. However, the possibility of some transactions not being immediately settled cannot be completely ruled out. To meet such exigencies, the proposed RTGS system provides for the maintenance of participant-wise payment queues in which payment transactions will be held in FIFO order within priority pending settlement.

 

The system also provides for facilities to the participants to view their respective transactions held in their payment queues, cancel such transactions and even change their priority. However, participants can only view transactions on their own payment queues. They can  not view  other participants’ queues or  their own pending incoming payment instructions.

 

F. Own Account Transfer :

 

The system provides for the participant-initiated movement of funds between various accounts held by it to optimise funds deployment and economise on its intra-day liquidity requirements. Such movement of funds can take place between the participants’ settlement and current account as also between two or more current accounts, held by a particular participant This can also be used as an effective tool for liquidity management by the participants.

 

G. Transaction Types :

 

The proposed RTGS system provides for a wide array of transaction types, which can be flexibly deployed to meet varying requirements.

 

The system provides for the inter-bank transaction type, which can be used to settle participants’ financial obligations on their own account. The solution also provides for a separate transaction type for customer payments, which can be used to transmit the customer information along with the payment message to the beneficiary’s bank in a structured format, which enables Straight Through Processing (STP) at the receiving participant’s end. Delivery Vs. Payment (DVP) transactions, emanating from the RBI’s Securities Settlement System, will also be settled in the RTGS system as a separate transaction type.

 

To provide for further flexibility, the system enables the use of code words to define new transaction types, based on the aforesaid primary transaction types, to meet the specific needs of the participants.

 

H. Liquidity and Collateral Management :

 

Any RTGS system entails active management of intra-day liquidity by all participants. To ensure smooth settlement of transactions and to avoid bunching of transactions and delay of credit to other participants, it is imperative that participants ensure, at the time of submission of payment instructions, that there are sufficient funds in their RTGS settlement account to settle their  transactions as soon as they are submitted or within a very short interval thereafter.

 

The RTGS system also provides several facilities and tools to aid and supplement the participants’ liquidity management efforts. The provision of a separate RTGS settlement account, own account transfers, queuing facilities and priority assignment are all examples of such tools. There are two additional powerful intra-day liquidity management utilities, offered by the proposed RTGS system viz. Intra Day Liquidity and Gridlock Resolution Mechanism.

 

I. Intra Day Liquidity :

 

The RTGS system enables the provision of intra day lines of credit by the Reserve Bank of India to the participants of the RTGS system to enable them to meet their intra day liquidity requirements. Such liquidity will be provided by the RBI at its discretion and under terms and conditions, to be specified by it from time to time. Such intra-day liquidity will be fully collateralised and will be provided to the participants at a charge per transaction. However, failure to repay the credit before the end of the day will invite strict penal action.

 

J. Gridlock Resolution Mechanism:

 

The solution provides for an optimised gridlock resolution tool to overcome crippling liquidity problems, which have the potential to clog the entire system. This tool may be invoked periodically or at the discretion of the RBI to enable smooth settlement of the RTGS transactions.

 

K. Interface with Net Clearing Systems- MNSB:

 

The Multilateral Net Settlement batches (the new avatar of the existing Clearing batches) will also be settled in the RTGS system. This will ensure more efficient settlement of net clearing batches including the settlement of the transactions, emanating from the Clearing Corporation of India Ltd. (CCIL) and potentially other clearing and settlement agencies as also  more efficient monitoring of un-cleared credit positions.

 

 

Chapter V

 

Integrated Accounting System- An Overview

 

The IAS provides the functionality developed for the Deposit Accounts Department, Department of Government and Bank Accounts and other Central Office Departments (CODs) which are Independent Accounting Units. The IAS system replaces the BASIS system as currently employed in DAD, Mumbai as well as the accounting softwares presently operational in DGBA and other IAUs.  In addition, it provides the functionality required for the computerization of some current manual processes for the aforesaid departments.

 

The IAS can be thought of as a Host system (the Central System resident on the S/390 machine) with a tightly integrated “front-end” system, the IAS User Interface (IAS-UI). The IAS central system provides:

 

·         A centralised database containing all information on transactions, the associated messages and master and control data required by the system.  This supports the processing of the IAS and other systems against the accounts maintained in the IAS database;

·         Links to external systems such that messages and files are sent and received as part of normal transaction processing. These include links to other RBI controlled systems, such as The Securities Settlement System (SSS) for security-related transactions (Loans and Treasury Bills), the Centralised Funds Management System (CFMS) and to other external organisations (such as RBI offices and customers) through the use of the SFMS message and file transfer services.

·         Full integration with the RTGS system to allow cross-IAS-RTGS transactions to be processed with no user intervention;

·         Integration with the cryptographic security module to provide a state of the art security solution using PKI-based cryptography;

·         Links to other local RBI department applications (for example - PAD and the Issue Department) through local messages and APIs;

·         A standby facility for the purpose of recovery of the system in the event of failure and fail over to the Disaster Recovery site.

 

Real-Time Gross Settlement (RTGS) System

 

Logically a part of the Integrated Accounting System, the RTGS system is that component of the Total Solution which enables the settlement of inter bank and customer transactions as well as Multi Lateral Net Settlement Batches on a real time basis with no user intervention. Architecturally, the RTGS system is logically partitioned system also resident within the S/390.

 

The RTGS system processes and controls the settlement of transactions across special purpose settlement accounts of the RTGS participants. The settlement accounts are dedicated current accounts which are funded at the start of day from each RTGS participant’s principal or subsidiary current account and zeroed at the end of the day by flushing out the remnant funds to the funding current account.

 

The system also provides for providing intra day liquidity to the participants’ settlement account to facilitate settlement of transactions when there are insufficient liquidity in the settlement accounts of the participants. The RTGS system interacts with the Securities Settlement System for the purpose of managing the collateral against which such intra day liquidity is granted.

 

The RTGS system also provides extensive enquiry and control facilities to RBI users through the command and control workstations.

 

Interbank Funds Transfer Processor

 

The Interbank Funds Transfer Processor (IFTP) is that component of the Total Solution which acts as an intelligent message switch for messages between the RTGS System and the RTGS Participant Interface.  The primary role of the IFTP is to strip out the commercial data of incoming RTGS payments and to request settlement of these transactions in the RTGS system.  The IFTP creates the necessary response and notification messages once the transaction is completed and sends them to the participants concerned.

The IFTP also provides for interfaces to the Securities Settlement System (SSS) to support the submission of the payment leg of the securities settlement process (DvP) and to Clearing Entities Interfaces to support the submission of Multilateral Net Settlement Batch (MNSB) transactions.

 

Participant Interface (PI)

 

This component of the Total Solution is a GUI-based front end which enables RTGS participants and Clearing entities to communicate with the central system through IFTP both for the submission of payment and MNSB transactions and for the receipt of notification messages. The PI, thus, acts as the single “Payment Gateway” for each RTGS participant. The PI system also provides various capabilities to enable backward integration of the system with the participant’s host system. These capabilities are provided in the form of message based APIs, file uploads and manual data entry into the PI. The PI server itself will reside in a Windows 2000 system and can have client machines connecting to it over a LAN or remotely over the WAN.

Three different types of PI are provided as part of the Total Solution:

 

PI for RTGS Participants;

PI for Clearing Entities;

The RBI PI.

 

The RBI PI is the PI to be used by RBI in its capacity as a member of the RTGS system. This PI is “special” inasmuch as it is fully integrated with the RBI’s “host” system (the IAS UI of DAD) through an API-based interface and also provides the additional functionality of enabling the submission of MNSBs and MNSB Returns on behalf of any configured Clearing Entity.

 

All PIs provide the functionalities for status tracking of transaction messages as also the submission of enquiries and control (e.g. transaction cancellation) requests to the IFTP system. In addition, the RBI PI provides transfer and status tracking of transaction messages to the IAS-UI server.

 

Integrated Accounting System User Interface (IAS-UI)

 

The IAS-UI provides a hub for RBI user interaction for normal banking operations carried out by RBI staff on the IAS-UI and IAU-CC workstations.  An IAS-UI server (resident on a Windows 2000 box) is provided for each IAU (including DAD and DGBA) independently.  Connectivity to the IAS system is provided locally (on a LAN) or remotely (over a WAN). IAS UI workstations may also connect to the IAS UI server over LAN or WAN.

The IAS UI servers provide transaction entry and enquiries facilities to users. The servers supports transaction entry through manual entry, file upload, message based inputs and receipt of transactions from other RBI departments through APIs.

 

The IAS-UI for DAD Mumbai provides a direct link to the RBI PI supporting the transfer of payments on behalf of the RBI and RBI customers.  This also supports the notification of payment statuses from the RBI PI to the IAS-UI.

The IAS-UI application supports the transfer of SWIFT messages within files with the PC Connect application in DAD.  Inward SWIFT message files, when received, are processed using IAS-UI user functions.  These functions also generate outward SWIFT message files which are accessible to the PC Connect application for sending to SWIFT.

User access is controlled via user profiles defined using a User Control Tool (which is a part of the Total Solution) and Smart Cards are used to authenticate known users.

 

IAS, RTGS and IFTP Command and Control Workstations

 

The Total Solution provides enquiry and control functionality (including the maintenance of system parameters and the addition and deletion of system data) for the RTGS and IFTP systems through command and control workstations. These are workstations which directly communicate with the S/390 system.

 

In addition, control facilities to modify configuration data and control the business day of each Independent Account Unit (IAU) are available to through the IAU Command and Control workstations. The availability of a set of control and configuration functions on the IAU CC instead of the IAS UI workstations facilitates greater control and the provides the option of making certain functions available only to a restricted set of users.

 

Document Management System (DMS)

 

The Document Management System is an application which provides the functionalities of scanning, storing and managing images of documents.  It is proposed to use Odyssey – a product from SRA Technologies – as the Document Management System for IAS.

 

This system can therefore be used as a repository of all important documents – central office circulars, account opening documents, power of attorneys, Demand Promissory Notes, etc, which are dealt with in DAD, DGBA and other IAUs.

While DMS may be used as a stand alone application, its functionalities are fully integrated with the Total Solution (in particular, with the IAS UI) enabling scanned documents to be linked to and registered with the associated transactions/objects. For example, the images of the account opening documents, viz. Account opening form, Board Resolution, Certificate of Incorporation, etc. can be linked to the account they are associated with.

 

DMS provides the functionalities required to scan, register, retrieve, export, import and archive documents. Each document in DMS is associated with a document type which can be used to group together similar documents. Documents can then be retrieved or enquired based on document types and/or keywords associated with the document. DMS provides the feature to export the image of documents and also to import them into the system from electronic documents.

Signature Capture and Retrieval System (SCARS)

 

The SCARS is an application for the capture and retrieval of physical signature images. The system enables the capture of signature images, their association with accounts/customers (for customer signatures) or with business areas (for staff signatures) and their retrieval for verifying the authenticity of signatures on documents against the stored images while entering and authorizing transactions through the IAS UI. For the purpose, SCARS is fully integrated with the IAS-UI functions requiring signature capture and verification.

 

SCARS also supports the specification of terms and conditions under which RBI staff and customer officials are authorized to sign documents, cheques, vouchers, etc. For example, individual amount limits for signing cheques and terms of signing (singly/jointly) may be specified using the functions of SCARS. Signature groups may also be defined to create groups of signatories who may be, for example, required to sign together. The system will itself verify these conditions during transaction execution and throw up error messages if any of these conditions are not satisfied.

 

For staff signatures, each staff signature may be associated with business areas for which the staff is authorized to sign. SCARS also supports the export of images of staff signatures, for example, for the purpose of circulating signatures of staff who are authorized to sign demand drafts.

 

Through SCARS, signatures of officers of other officers and institutions who are authorized to sign instruments and remittances may also be maintained and used for verification.

 

Integrated Accounting System & Business Areas :

 

The Integrated Accounting System provides for facilities for automating the various accounting related functionalities of DAD, DGBA and the CODs which are independent accounting units.

 

The IAS system is divided into various business areas. Each Business Area provides a distinct set of functionalities as part of the Total Solution. However, no business area is an independent component of the system. Each business area needs to source the functionalities provided by one or more of the other business areas in order to be able to fulfill its role. For example, the Current Accounts business area needs to access the functions of the Cash Business Area in order to enable a transaction involving cash withdrawal by a customer to be recorded in the system.

 

A list of the business areas in the IAS and a brief description of the functionalities are as under :

 

(a) Current Account:

 

This business area provides a set of functions for the maintenance of customer current accounts in DAD. The module interacts with various other business areas to provide these functions. The set of functions provided include facilities for:

 

·         Opening, closing and transferring of current accounts 

·         Acceptance of documents for opening of accounts and their association with the account being opened (using the services of DMS)

·         Maintenance of special instructions for the operation of current accounts 

·         Capture of signatures of authorized customer officials (through the SCARS module) and the definition of the terms and conditions for their operations on the current account.

·         Accepting and defining standing instructions for the automatic transfer of funds from/to customer accounts (through the Standing Instructions module).

·         Facility for investing the surplus funds in customer accounts in Government of India rupee securities and their disinvestment when funds are required (through the Treasury Bills module) 

·         Facility for putting though transactions in customer accounts

·         Facility of generating account statements and their automatic dispatch to customers through SFMS messages or e-mail at defined periodicities which can customized for each customer

·         Facility to receive and pay cash from/to customers 

·         Facility for automatic generation of balance confirmation statements periodically and for monitoring the receipt of confirmations 

·         Facility for blocking of funds in current accounts and their subsequent unblocking

·         Facility for freezing the operations of current accounts 

·         Facility for defining customer “account types” to enable logical grouping of participants for purposes of defining common properties and for ease of reporting.

·          

(b) Loans and Advances:

 

This business area enables the definition of loan schemes that are introduced by various Central Office Departments under various RBI Act provisions and the maintenance of loans and advances granted to the Bank’s customers under these schemes. This business area also provides a crucial interface to the RTGS system to enable the RTGS system to make available Intra Day Liquidity to its participants.

 

Facilities for defining new schemes in a flexible manner and with a view to taking care of new schemes which may be defined in the future has been provided as part of this business area. Additionally facilities for collateral management, marking of securities to market, management of eligibility limits, interest rates, maturity profiles and other activities associated with the management of loans 

 

Loan Schemes are defined based on a set of parameters – different combinations of these parameters enable the definition of a variety of loan schemes. An illustrative list of such parameters and the various functionalities for the maintenance of the Bank’s loan portfolio is detailed below:

 

·         Provision for classifying loans as short term, medium term and long term loans 

·         Provision for defining loan slabs on the lines of the present Normal and Backstop facilities. Up to five loan slabs may be defined for each loan scheme. Also, separate interest rates for each slab may be defined 

·         Provision for defining differential interest rates based on duration can be defined. This is to take care of loan schemes in which interest is charged based on the duration that a particular loan is outstanding. Thus, interest may be charged at a particular rate for the first fifteen days and a higher rate for the subsequent days. Also,

·         provision for charging interest based on slab rates or at a flat rate is provided.

·         Provision for specifying whether or not a loan should be collateralized as well as specifying the types of securities which are eligible to be accepted as collateral for such loans and the margin to be applied for such securities. The system also provides a facility to maintain current market rates of such securities (as received from the Securities Settlement System) to value the securities accepted as collateral.

·         Provision for specifying repayment schedules – number of repayments and percentage amount to be repaid can be specified in a grid, if applicable to the loan scheme. Repayment schedules can be defined for the loan as a whole or for each instance of disbursement of the loan 

·         Provision for specifying whether the loan scheme permits a single disbursement/repayment or multiple disbursements/ repayments

·         Provision for specifying minimum and maximum amounts permitted for disbursements 

·         Provision for specifying loan schemes such as the General Line of Credit scheme for NABARD in which the sanctioned limits under the two parts of the scheme (GLC I and GLC II) are interchangeable.

·         Provision for defining schemes as such Export Refinance where the limits applicable for a particular customer are accepted periodically and actual drawing capability validated at the time of making a loan disbursement.

·         Provision for specifying over riding parameters for a particular customer –margins, interest rates or security types eligible for collateral different from that specified for the loan scheme.

·         Provision for revaluation of securities accepted as collateral at periodic intervals and facility for sending electronic messages to customers to furnish additional collateral in case of shortfall of securities  Provision for adding and/or swapping securities received as collateral

·         Provision for automatically recovering interest on outstanding loans at specified periodicities and for calculating accrued interest for various periods

·         Provision for monitoring of expiry of Demand Promissory Notes, maturity of loans, etc. through start of day reports

·         Issue Balance Confirmation Statements automatically at defined intervals and receive their response electronically.

·         Provisions for specifying obligants and co-obligants for loan schemes.

 

(c) Remittances

 

This business area provides the facilities for the issue and payment of remittances between RBI offices, agencies and embassies and for the various associated functions including cancellation, revalidation, issue of duplicate drafts, advice noting, payee name correction, payment of drafts ex advice, etc. The capability of processing the demand draft and telegraphic transfer forms of remittances have been provided as part of the system.

The IAS has provided for the capability of handling the receipt and generation of a large number of electronic messages some of which can be processed without any user intervention.

The following SFMS messages are received/sent over INFINET by this business area:

 

v  DD Issued Advice with TRA;

v  DD Cancellation Advice with TRA;

v  DD Paid Advice;

v  Non Payment Certificate message;

v  Duplicate DD Issue advice;

v  Revalidation DD Advice;

v  Payee name correction advice.

v  TT issue confirmation Advice;

v  TT Paid Advice;

v  Acknowledgement for the TT cancellation request;

v  TT issued TRA;

v  TT Cancellation request;

v  TT Purchase message;

v  TT purchase confirmation Advice;

v  TT Realisation Advice to Issuing office and Customer;

v  TT Realisation Failure Notification;

v  TT Cancellation TRA.

 

Further, the system provides the capability of handling the following messages in an STP fashion i.e. without user intervention, if so configured:

v    DD Issued Advice with TRA;

v    DD Cancellation Advice with TRA;

v    TT Issued Advice with TRA;

v    TT Cancellation Advice with TRA;

v    Demand Draft Advice Noting

Ø   Drafts Issue Advice;

Ø   Duplicate Drafts Issue Advice;

Ø   Draft Cancelled Advice;

Ø   DD Stop Payment Advice;

Ø   Non-Payment Certificate;

Ø   DD Paid Advice;

Ø   Payee name correction advice;

Ø   Revalidation DD Advice.

v    Telegraphic Transfer Advice Noting

Ø  TT Issue Confirmation Advice;

Ø  TT Paid Advice;

Ø  TT Realisation Advice;

Ø  TT Cancellation Advice; 

Ø  Acknowledgement for the TT cancellation request;

Ø  TT purchase confirmation Advice.

 

Irrespective of whether or not electronic messages are configured to be processed without user intervention, they facilitate considerable reduction in data entry effort. The system also provides for a host of value additive functionalities like monitoring the number of outstanding TTs purchased, automatic recovery of interest of late realization of TTs, maintaining maximum remittance limits for participating agencies (to take care of needs of treasuries and sub treasuries), maintenance of customer wise details about  TT purchase eligibility, minimum amount of TT which must be purchase/issued and maximum limit of TT purchase, facility to maintain instances of Treasury Irregularities; facility to maintain agency wise details of eligibility for various kinds of remittances, etc.

The system generates all the accounting entries related to remittances as well as associated charges. Two functionalities are provided for the accounting of remittances issued on agencies. The proceeds of the remittance can be credited to RBI General Account, CAS Nagpur. It can also be credited to the current account of the agency maintained in the local DAD. This is to take care of a possible change being considered by the Bank to the manner in which agency remittances are accounted for.

 

(d) Inter Branch Operations

 

This business area encompasses the various functions linked to the operations of the RGI General Account. Two new features of the operations of the RBI General Account are being introduced with the Integrated Accounting System: The functions provided include:

 

v  Facility for maintenance of Responding Branches to which Transfer Responding Advices (TRAs) will be sent and from which TRAs will be received.

v  Facility of maintaining RBI General Account schedules as prescribed by DGBA

v  Facility for maintenance of RBI  General Account transaction types for the classification of various TRAs depending upon the nature of the underlying transactionsFacility for generating TRAs and sending them to the destination centers as SFMS messagesFacility for receiving inward TRAs in paper form and as messages and forwarding these TRAs to the concerned sections which have to respond the transction

v  Facility for marking off originating TRAs based on paper or electronic messages once they have been responded

v  Facility for Cancellation/Withdrawal of originating TRA messages – in case of cancellation, another TRA is originated reversing the effect of the earlier transaction while in case of withdrawal, no new TRA is generated. The latter is typically used when the original TRA has not been sent to the responding office.

v  Certain miscellaneous transactions such as monthly transfer of government balances to CAS, Nagpur are also provided as part of this business area

v  Facility for automatic dispatch of periodic reminders to responding offices and departments in the matter of un-responded TRAs

 

(e) Foreign Accounts

 

This module caters to the special needs of the Bank’s international customers and of the needs of the Bank’s operations in the foreign exchange market.

 

 The module provides for the maintenance of current accounts of international customers like the IMF, World Bank and foreign central banks like the Nepal Rashtra Bank. These accounts are maintained and operated under special instructions like: 

·         Automatic investment of surplus funds

·         Automatic disinvestments of earlier investments to meet funds deficit situations 

·         Maintenance of foreign currency denominated accounts

·         Account statements in specified formats and periodicity

·         Payment of interest, etc.

 

The Foreign Exchange business area has provision for automated availability of these facilities.

The business area also provides facilities to account for the rupee leg of the Reserve Bank’s foreign exchange transactions. The system has the capability of handling electronic messages received from DEIO in this respect and of, optionally, processing them without user intervention.

Also, the entire functionality to maintain the account for the Bank of Foreign Economic Affairs of Russia (BFEA) and to process the rupee and dollar denominated Letters of Credit (LCs) issued by the BFEA have been provided as part of the Integrated Accounting System. The functionalities include:

 

v  Record and register LCs

v  Record and register amendments to LCs

v  Payment of LCs

v  Deletion of LCs

 

Facilities for processing both rupee and dollar LCs are provided in the system and this business area is fully integrated with the current accounts business area to enable all accounting entries to be automatically generated.

 

The system provides facilities for performing these operations based on electronic messages received from BFEA or the designated bank, as the case may be. Messages from BFEA are received as SWIFT messages while messages from designated banks are SFMS messages.

 

The system also provides several  value added functionalities like maintenance of designated banks, blocking funds in the current account of BFEA when a LC is registered and unblocking the funds when payment has to be made, maintenance and monitoring of LC details like retention amounts, automatic advices to all concerned when a LC is registered or paid, sending of electronic objection memos, etc.

 

This business area also provides the facilities for maintaining foreing currency rates and of revaluing foreign currency accounts based on DEIO messages.

 

(f) Cash

 

This business area provides the full functionalities required to manage DAD’s cash operations including receipt and payment of cash to/from the Issue Department, receipt and payment of cash on behalf of the Bank’s customers and staff and generation of the currency transfer TRA.

 

The entire range of functionalities required for the purpose including maintenance of denomination wise details of cash balance, receipt and payment of cash and exchanging denominations are a part of this business area. Additionally, there is a provision to add new denominations if and when they are notified and introduced.

 

This module also provides for automating and monitoring the flow of cash within the banking arm of the Cash Department. The banking cash balance will be held in a “vault” from where cash will be distributed to the tellers. Each teller will be allocated a till and will have to electronically acknowledge the receipt of cash from the vault. The Deputy/Assistant Treasurer in charge of the vault will also have to similarly acknowledge the receipt of cash when it is received back from the tills.

 

Provision for the entire functionality for automating the accounting of the currency chest transactions in DAD has been made under this business area. These transactions are special inasmuch as they are cash transactions not involving the movement of physical cash in DAD. Each currency chest transaction is simultaneously treated in the system as a receipt/payment of cash from the Issue Department and a payment/deposit of cash from the concerned currency chest bank. The system not only generates the necessary accounting entries for the purpose but also takes these transactions into account for the purpose of calculating the currency expansion/contraction figure for the office.

 

The system also provides for the automatic calculation of the currency expansion/contraction figure for the office and the generation of the currency transfer TRA to DGBA at the close of every day.

 

(g) Clearing

DAD is also a member of the clearing house inasmuch it presents instruments in clearing on behalf of its customers and other RBI departments and also receives instruments for payment issued by itself (payment orders), customers, RBI offices (drafts) and by central office departments.

 

This business area attempts to provide the necessary functionalities for DAD’s participation in different types of clearings, the accounting of such transactions and the monitoring of differences arising out of clearing. The functionalities in this business area include:

·         Facility for capturing the details of outward clearing instruments and generating the outward clearing list for presentation in different clearing types including ECS and EFT

·         Facility for specifying properties of clearing types including permitted amount ranges, restricted branches, etc. to prevent erroneous presentation of instruments 

·         Facility for generating the accounting entries once acknowledgement of the presentation has been received 

·         Facility for capturing of details of returned instruments (through manual entry or automatic file upload) and the associated accounting of these returns

·         Facility for automatic credit of the proceeds of collected instruments to the beneficiaries’ accounts once the clearing cycle is complete 

·         Facility for receipt of inward clearing details and their automatic upload into the system and, after being passed for payment, their automatic debit to the relevant account or their return with return memos

·         Facility for marking instruments as ‘Listed but not Received’ and “Received but not Listed” and for generating the Error List  Facility for monitoring of clearing differences

·         Facility for interaction with different business areas for collection of cheques on their behalf – e.g. cheques purchased and cheques against remittances and for uploading and posting of inward clearing instruments

 

(h) Collections

 

DAD provides cheque purchase facilities to its staff and to certain select customers. It also collects outstation instruments and credits the proceeds to the account of the beneficiary. The functions required to purchase cheques, collect outstation instruments and to monitor such activities are provided in IAS as part of this business area.

 

The functionalities provided in this business area are divided into two broad categories: 

 

·         Pay and Collect – for purchased instruments

·         Collect and Pay – for collection instruments

 

Facility for collection of instruments of both the above categories are provided by various channels – through an interface with the clearing module for local cheques purchased, through or on behalf other RBI offices, through correspondent banks like the SBI and through local banks which do not participate in clearing.

 

The system also provides for the accounting and monitoring of such transactions. For the purpose, a set of DDRR accounts will need be opened which will, inter alia,  enable keeping track of instruments of various kinds, their collection or return, credit of proceeds to beneficiary accounts (in case of paid collection instruments) and recovery of proceeds from the purchaser (if a purchased instrument is returned unpaid), automated dispatch of reminders to collecting agencies (other RBI offices and correspondent banks) in respect of outstanding instruments.

 

The business area also provides for electronic messages wherever relevant (i.e. when the instrument does not move with the TRA) and for automating the processing of messages where feasible, for example when a message is simply used for marking off a cheque purchase transaction.

 

The system also provides for recovering charges for cheque purchase and collection of instruments (including penal charges) as part of the transactions themselves.

 

(i) Standing Instructions

 

This module provides facilities for automatically executing funds transfer instructions based on pre-defined system and business events e.g. at the end of a business day or when the balance in a customer’s account goes above a pre-specified value. Two types of standing instructions can be defined in the system: 

 

·         Standing Instructions based on frequency – standing instructions based on various frequencies can be specified and such standing instructions can be configured to execute at start of the due date for execution or at end of day

·         Standing Instructions based on available funds in an account -  such standing instructions are executed during the course of a business day such that the instruction is executed only if the balance in the account falls below or above the specified amount

 

 The facilities in this business area provide the necessary tools to automate funds transfer activities of a defined regular nature. Through the use of the facilities provided here, considerable manual effort can be saved and the need to keep diary notes of certain events can also be precluded.

 

The Standing Instructions can be defined  to achieve simple transfer of funds from one account to another in the same or another centre (through the RBI General Account); it can also be used to automatically invest surplus funds in specified accounts in government securities and/or disinvest earlier investments in government securities in case of shortfall of funds in the account. Standing Instructions can also be defined to transfer funds in an account which are over and above a specified minimum balance.

 

This business area provides the set of functions for defining Standing Instructions based on paper documents (which will be scanned in the DMS and registered along with the Standing Instruction) or electronic messages received from customers. Different options are available to customize these instructions, e.g. option for specifying “Holiday Processing” i.e. if the due date for execution falls on a holiday, then option for specifying whether the standing instructions will be executed the previous day, the next day or will not be executed at all. Similar options are available for the case when the next date of execution falls on the annual closing day.

 

Provision for specifying instructions for one time execution as also for temporarily suspending the execution of a standing instruction have also been made. The system also provides for charging customers for the execution of standing instructions. Separate charges may be configured for successful and for failed execution attempts enabling penalty charging for failed standing instructions, if considered desirable.

 

If so configured, the customers can be automatically advised when a standing instruction is executed. Management information reports about the execution of standing instructions including failed attempts are also generated.

 

(j) Treasury Bills and Interest Warrants

 

This functional area of the IAS makes available the facility of investing in government securities on behalf of customers (the system interacts with SSS for the purpose of transfer of securities) and their subsequent disinvestment or maturity. It also provides the facilities to service interest warrants and repayment orders on behalf of institutions like NABARD.

 

As part of the first functionality, the system provides the facilities for investing the surplus funds of customers in specified government securities and of generating the necessary accounting entries in this regard. The system also provides for specifying minimum investment amounts and multiples in which investment can be made for each customer separately thereby reducing the effort of keeping track of such details at the time of making individual investments and also minimizing errors.

 

The system keeps track of investments which are due for maturity and keeps track of whether or not the maturity proceeds have been received in the customer’s account. In case of shortfall of funds or at the request of the customer, any investment made by the customer can be disinvested.

 

The details of the securities in which such investment can be done is maintained in the system along with details such as the discount rate and the rediscount rate for investment and disinvestment respectively.

For these transactions, the Integrated Accounting System interfaces with both Public Debt Office (SSS) and PAD for transfer of securities and funds respectively.

 

For the servicing of interest warrants  and repayment orders issued by select financial institutions like NABARD, facilities for receipt of advices from the institutions and the payment of interest warrants by debit to a special purpose local current account or to a current account maintained in another DAD centre are provided.

 

Advice details may be registered in the system based on data received in a file. The details may also be received as messages in which case they can be uploaded with no user intervention.

 

Separate debit accounts may be configured for servicing of interest warrants and of repayment orders. Also, signatures of the institution issuing the warrant/repayment order can also be maintained in the system using the services provided by SCARS and used for verification at the time of paying the instruments.

 

(k) Inventory

 

This module provides the functions for the maintenance of security paper (cheques, payment orders, drafts). The system allows recording of the receipt of fresh instruments from the printing presses, their issue to customers/departments, their subsequent payments and the issue and revocation of stop payment requests. All modules which use security paper (Remittances, Current Accounts, Payment Orders, etc.) need to avail of the services of this business area.

 

This is a support business area which provides a centralized inventory management solution comprising the functionalities required to: 

 

·         Manage the stock of different types of instruments

·         Monitor the issue of instruments to customers and to other departments 

·         Monitor the usage of instruments for the issue of drafts and payment orders by the department 

·         Manage the Issue and revocation of stop payment instructions for different instrument types both electronically and in paper form

·         Manage the receipt of stop payment and revocation advices through messages, paper requests and over telephone (in the case of telephonic stop payment advices, the system provides the facility of receiving the actual paper advice subsequently; in case the instrument is presented for payment in the meantime, the system does not prevent payment but throws up a warning which can be overridden with higher authorization) 

·         Track the status of instruments viz. issued, stopped, paid, destroyed, etc.

·         Accept broken instruments from customers and departments and track the time of their destruction 

·         Provide the facility for printing different types of instruments – in a batch or automatically on the completion of the transaction which requires printing 

·         Control the usage  of instruments for printing and reprinting of payment orders and drafts – instruments are selected for printing by incrementing the serial number of instruments from the vault; any change in the instrument number of the user will be permitted only after ensuring that the user enters the reason for the change

 

(l) General Ledger and Internal Accounts

This is the core business area of the IAS which maintains the general ledger of each IAU, including DGBA and DAD. All business areas need to interact with this module whenever any accounting entry has to be generated/passed as every accounting entry is ultimately reflected in the general ledger.

The business area provides the facility for a host of functions including:

 

(a) Maintenance of General Ledgers, sub General Ledgers and Break General Ledgers – IAS provides the functionalities for maintaining the general ledgers of each accounting unit in a three tier structure of GLs, sub GLs and break GLs. Accounts can be associated with a GL at any level of the hierarchy.

While this structure exists even today in BASIS, it has been used only for a few General Ledgers e.g. Sundry Deposits and Charges.

 

(b) Maintenance of GL categories – The system provides for the facility of associated each GL, sub GL and break GL with a category which is defined by the user and can be used to group together GLs, sub GLs or break GLs for reports. The system uses this GL category for the production of weekly and annual reports in which GL accounts of type “Other Assets” are grouped together, for example.

 

(c) Generation of profit and loss  statements – the system provides the capability of capturing provisions for income and expenditure (including calculation of the provisional amounts for interest receipt and depreciation), generating the accounting entries for year end provisions, producing the profit and loss accounts – both annual and provisional statements for any defined period. The system also provides the facility of accepting data regarding budgetary and projected figures pertaining to income and expenditure accounts and for generating relevant statements.

 

(d) Annual closing functionalities – the set of activities related to the annual closing of accounts are totally automated in the system with provisions to generate various annual closing statements, to automatically transfer GL balances to and from the Balance Account and to automatically reverse the

 

entries in the Adjusting Account. Various functionalities for annual closing in DGBA are also provided – these are discussed later in this document.

 

(e) Maintenance of the Dead Stock Account – the system provides the required functionalities for maintaining the Dead Stock Account. The system provides the facilities for the accounting of activities like the purchase of new dead stock items, sale of dead stock items, transfer of dead stock items to other IAUs, improvements in dead stock (for example when a building is renovated) and writing off dead stock. Each dead stock item is associated with a “major” dead stock category (which defines the Bank’s deprecation policy pertaining to the item) and a minor category (which groups items of similar nature for ease of consolidation and reporting). The system also provides for the special processing of dead stock items which are part of the Bank’s FRO scheme and for automatically calculating and applying depreciation.

 

(f) Maintenance of Internal Accounts – this business area provides for the functionalities related to the opening, closing and maintenance of internal accounts and for the accounting of transactions in these accounts. The system provides facilities for automatically configuring the periodic  generation of account statements and balance confirmation statements and their electronic dispatch to specified SFMS destinations (if IFSC codes are available); for specifying the eligibility of the internal account for issue of cheque books; and a facility for indicating the accounts whose balance should be zero at EOD. Each internal account can also be configured to lapse at the end of a specified period wherein the outstanding entries in the account will be transferred to another specified account in the same IAU or to another IAU through the RBI General Account.

 

(g) Maintenance of Payment Orders - This business area also provides the functionalities associated with the issue, payment, revalidation, cancellation and duplicate issue with respect to payment orders.

The functions for the maintenance of internal accounts of each IAU, (e.g. the Sundry Deposits, Charges, Suspense, Dead Stock, etc. accounts) and the accounting of transactions in these  accounts are also provided as part of this business area.

 

(m) DGBA functionalities

 

This business area provides a set of functionalities which are unique to DGBA in its role as central office of banking departments and the accounting unit of the Bank as a whole. The functions provided by the system include:

 

·         Facility for maintaining Issue office and IAU details for recognizing them for the purpose of consolidating Bank’s Accounts.

·         Facility for receipt and consolidation of weekly statements from all IAUs for the preparation of Weekly Balance Sheet and its associated reports for Banking Department.

·         Facility for receipt and consolidation of daily Currency Transfer Reports from the various issue Offices and for arriving at the net transfer of assets required between the Issue and Banking Department Balance Sheets

·         Facility for receipt and consolidation of A8-A9 statements from all the Issue Offices, maintenance of Proforma Accounts in this respect and preparation of the Issue Department Weekly and its associated reports such as abstract of Circulation Notes Account, Government Stocks with RBI etc.

·         Facility for maintaining the record of mint-wise, issue office wise and denomination-wise coin balances and for tracking of Inter Circle Remittances and the reconciling thereof.

·         Facility for receipt of Annual Closing Statements by all the IAUs/Issue Offices and their consolidation to produce the Bank’s Balance Sheet and Annual Accounts (both for Issue and Banking Department) of the Bank.

·         Facility for performing special  processing such as adjustment in the RBIGA balance while preparing the Weekly Statement of Affairs to take care of differences in government balances reported by CAS, Nagpur figures and by the various offices, adjustments required to take care of overdrafts reported by CAS, Nagpur for states, posting and reversing Year End Items-in-Transit transactions etc.

·         Facility for receipt of other periodic statements such as Proforma Profit and Loss Statement, Sundry/ Suspense statement etc and for processing them to generate useful information.

·         Facility for receipt of Transactions Details of the both the originating and responding RBI General Account transactions from all the IAUs in the predefined schedules, generation of the relevant accounting entries in this respect and the reconciliation thereof.

·         Facility for maintaining Bank’s Rupee Investment Account. The set of functionalities provided for this purpose include accounting for new investments in Government Rupee Dated Securities/ Treasury Bills/ Gold/ Shares/ Foreign Securities etc, through Auction/ Devolvement/Reissue, Investment/ Disinvestment through Open market Operation/ Liquidity Adjustment facility, maturity of investments, receipt of periodic interest/ dividends etc.

·         Facility for swapping securities/investments between the issue and Banking Departments

·         Facility for maintaining the Bank’s Gold Account – facility for revaluation of existing holdings of gold and for accounting for sale and purchase of Gold by the Bank.

·         Facility for accounting for the acquisition of Rupee Coins into the Bank’s stock from Government Stock.

·         Facility for tracking the receipt of statements from various issue offices and IAUs, and enabling the preparation of consolidated statements. Where reports from all IAUs/Issue Offices have not been correctly received, the system enables  the generation of the consolidated statement using the data from an earlier dated report or by ignoring the data of that IAU/office. In either case, the list of such offices/IAUs is provided in an annexure to the report.

 

The system enables the receipt and processing of various reports from IAUs/Issue Offices in both paper and electronic form saving considerable manual effort in DGBA.

 

New/special features of the Integrated Accounting System :

 

The Integrated Accounting System will introduce several new features and processes in the functioning of DAD, DGBA and other accounting units. Many of them are the results of efforts to leverage technology to improve work practices and provide better customer service. Some others are actual changes to the work flow in the departments for the purpose of better control and/or accounting practices.

 

Some of these new features have already been discussed earlier in this document e.g. the Signature Capture and Retrieval System, the Document Management System, the Standing Instructions module, the increased functionalities of the Loan and Advances module which seeks to provide the full collateral management functions, a centralized inventory management solution,  full fledged clearing and collections modules and a full set of functionality for the Department of Government and Bank Accounts.

 

In other areas, attempts have been made to improve or expand existing functionalities and have been described above. Some examples are automatic balance confirmation statements for internal accounts, centralized inventory management, the four tier General Ledger-Account structure, monitoring of limits for customers and for agencies for remittances, blocking of funds in the current account of BFEA while registering an LC, etc.

 

Some others new features of IAS are described below:

 

SFMS messages and Straight Through Processing

 

Messages :

 

The IAS system provides the capability of sending, receiving and processing electronic messages. The system deals with a large number of messages for a wide number of functionalities including:

 

·         Payment messages from RTGS participants 

·         Response messages from the RTGS system to participants

·         Messages from clearing houses giving details of Multilateral Net Settlement Batches.

·         Account opening sanctions from DGBA

·         Loan Sanctions from various central office departments 

·         TRA messages  Remittance related messages

·         Funds transfer messages from customers 

·         Message for placing standing instructions 

·         Message for requesting a loan disbursement

·         Message for requesting a loan repayment 

·         Message for issue of cheque books

·         Current transfer message

·         Message to SSS for requesting transfer of securities

·         Message from SSS for transfer of  funds in respect of its debt service obligations e.g. interest payments, maturity proceeds, etc.

·         Message for confirmation of balances, etc.

 

The capability of handling electronic messages confers a number of benefits including reduced manual data entry work. It also opens up the possibility of handling certain kinds of transactions without user intervention.

 

Straight Through Processing :

 

IAS provides the option of completely automating certain kinds of activities which can then be carried out without user intervention. Such transactions are largely based on receipt of electronic messages and STP is possible only when the complete input requirements of the transactions are received electronically in the specified format.

 

The most important set of transactions which will  be processed without any user intervention are RTGS transactions. Apart from this, provision for the processing of two kinds of transactions without user intervention has been made in IAS. The first kind of STP transactions comprises those transactions which will always be carried out in an STP fashion. The second kind comprises transactions which may be configured to be carried out in an STP fashion or may be configured to require user intervention.

 

The first set of transactions includes: 

 

·         Marking off of Balance Confirmation based on electronic balance confirmation certificates from customers 

·         Receipt and processing of electronic  TRA messages and the transfer of their proceeds into the Sundry Deposits or Suspense Account.

·         Funds transfer requests from CFMS 

·         Standing Instructions

·         Advice noting for demand drafts issued

 

The second set of transactions/functions for which STP is enabled but is not mandatory include: 

 

·         Payment of incoming TT messages 

·         Incoming RTGS payments which are credited to the RBI Settlement Account by the RTGS system but the proceeds need to be credited to the final beneficiary’s account.

·         Debt Servicing transactions (e.g. interest payments) received from the Securities Settlement System

·         Reversal of inward TRAs from the Sundry Deposits or Suspense Accounts where they have been parked in the first leg of TRA processing

 

PAD interface

 

The IAS proposes to replace the present inter departmental  Transfer Scroll which is presently used to route transactions between DAD and the Public Accounts Department by a mechanism which uses two intermediary accounts - the PAD Sundry Deposits Account and the PAD Suspense Account in conjunction with a messaging interface between the two departments and with the APIs being provided as part of the IAS to enable automatic voucher posting by other departments.

 

This mechanism is aimed at ensuring that:

 

1.   The books of DAD are always balanced

2.   No credit takes place in DAD unless the contra debit in PAD has first taken place and vice versa

3.   An instant snapshot of all transactions between DAD and PAD is always available

4.   Differences in the books of accounts, if any, can be more easily traced as they can be localized to specific transactions which may be causing the difference.

Let us take the example of a DAD-initiated transaction which debits a government account and credits a current account to understand how this mechanism works. On receipt of the transaction, DAD sends an electronic “Debit Request Message” to PAD giving particulars of the account to be debited and the amount of the debit. On receipt of the message, PAD debits the government account and uses the API provided by the IAS to credit the PAD Sundry Account. PAD then sends a “Debit Confirmation Message” to DAD along with the reference number of the entry in the PAD Sundry Account for reversal. On receipt of the message, DAD credits the current account by reversing the entry in the PAD Sundry Account.

 

In case, of a transaction which needs to credit a government account, DAD will debit the concerned account and credit the PAD Sundry Account. It will then send a ‘Credit Confirmation Message’ to PAD with details of the account to be credited, the amount and the reference number of the transaction in the PAD Sundry Account. PAD debits the PAD Sundry Account through the API using the reference number  provided by DAD and credits the concerned government account.

 

The PAD Suspense Account is used when a government account has to be debited as a result of a MNSB transaction e.g when the General Post Office Account has to be debited. In this case, the system does not send a “Debit Request Message” to PAD nor does it wait for a confirmation of the debit. It simply debits the PAD Suspense Account and sends a Debit Notification to PAD along with the reference number of the entry. PAD reverses the entry in the PAD Suspense Account by using the API provided for the purpose and debits the concerned government account.

 

A similar mechanism is followed when the transaction is initiated in PAD. At the end of the day, the PAD receipts and payments scroll can be uploaded in the system through a special function provided for the purpose. End of day is not permitted if the balance in the PAD Sundry and Suspense Accounts are not zero.

 

RBI General Account – A revised approach

 

Under the IAS, a new procedure for the transmission of TRAs and for their accounting is proposed to be introduced for the RBI General Account. This mechanism is expected to facilitate faster response and speedier reconciliation of RBI General Account transactions.

 

There are two aspects to the new mechanism – the transmission of TRAs from the originating office/department to the responding office/department and the treatment of the inward TRA at the responding office.

 

TRAs will be transmitted in the form of SFMS messages from one office/department to another immediately on completion of a transaction (except in case of transactions like drafts where a consolidated TRA is sent; in this case, the TRA will be transmitted at the end of the day). Although, the option of generating and sending the TRA in its present paper form will still be available, transmitting the same electronically will be the preferred mode both because it reduces manual effort and also because the message is instantaneously delivered to the responding office/department in an assured manner through SFMS. Also, a TRA received electronically can be processed faster and with much less effort as described below.

 

At the responding office/department, the TRA will be immediately responded and the proceeds parked in a special Sundry Deposits or Suspense Account (depending on whether the TRA is a debit or credit TRA). This process will be done automatically by the system when the TRA is received electronically.

 

The proceeds of the TRA will be actually debited/credited to the destination account by contra credit/debit to the Sundry Deposits or Suspense Account, as the case may be as and when it is possible for the office/department to actually respond the transaction. While the originating office/department will receive an acknowledgement when the TRA is received by the responding office/department, the transaction will be marked off in the PAD048A register only when the entry in the Sundry Deposits or Suspense Account is reversed i.e. when the transaction is actually responded.

 

This method will be implemented not only in those offices/departments which will function under the IAS, but in all the offices/departments. For example, pending introduction of IAS in DADs other than Mumbai, BASIS may be modified to ensure that when an inward TRA is registered through the “Inward TRA Registration” function, a set of accounting entries are generated to park the proceeds of the TRA in the designated Sundry Deposits or Suspense Account.

The advantages of this proposed method are many:

 

·         All outstanding entries in the RBI General Account are essentially contingent assets or liabilities for the office/department which is required to respond the entries. The proposed mechanism ensures that all such contingent assets and liabilities are actually reflected in the books of accounts of that office/department.

·         Transactions in the Sundry Deposits and Suspense Accounts are typically under the close scrutiny of the Heads of Offices/departments and of auditors and inspectors. The outstandings, if any, in these accounts are closely monitored and followed up. This same scrutiny will, under the new mechanism, become applicable to RBI General Account transactions ensuring their prompt reversal.

·         IAS provides the ability to configure these designated Sundry Deposits or Suspense Accounts in such a way that transactions, especially large value transactions, outstanding in the account for more than a day, a week or any desired period will be automatically notified to DGBA. This will enable more vigorous and effective follow up and monitoring of RBI General Account transactions by DGBA.

·         In DGBA, all RBI General Account transactions will be reconciled on a day to day basis. The problems posed by wrong reporting, part responding of transactions, late response of transactions, etc. will be considerably reduced.

·          

 RBIGA Transaction Type

 

A RBI General Account transaction is typically one in which one leg of a transaction is in one office/department and the other leg in another office/department. In case of many such transactions, the data entered in the originating office may be very similar to the data entered in the responding office. For example, in a transaction involving TT issue, the details of the customer purchasing the TT is required to be entered both in the office from where the TT is issued and in the office where it is to be paid. This is exactly the kind of situation where technology can be harnessed to achieve Straight Through Processing (STP) in the responding centre or, at least, to prevent similar data from having to be entered a second time.

 

To facilitate this, the concept of a RBIGA transaction type has been introduced in IAS. Each transaction type is associated with a particular kind of transaction involving the RBI General Account commonly used in DAD, DGBA or other central office departments e.g. TT transactions, Draft Issue transaction, Currency Transfer transactions, outstation cheque purchase transactions, rupee leg of the Bank’s foreign exchange transaction, etc. Each transaction type has been associated with a particular format of a SFMS message which represents the format in which the TRA will be transmitted to the responding office/department.

 

Each message corresponding to a RBI transaction type comprises two parts. The first part, styled the “Generic TRA format” comprises the fields common to every TRA – e.g. TRA number, originating and responding office codes, date, schedule, amount and particulars. There is an additional field for department code in the generic TRA format which enables the originating office to specify which department at the responding office is expected to respond the TRA. This enables easier routing of the TRA in the destination centre. Where the department cannot be specified, DAD is considered to be the default department code.

 

The second part, which is specific to the particular transaction type, contains fields which are different for each message and enable communication of details regarding the transaction in a structured manner which can be read and understood by the destination system.

 

Additionally, each RBI General Account transaction type can be configured to correspond to particular schedule numbers, as defined by DGBA. This ensures that transactions will always be originated/ responded in correct schedules reducing the possibility of data entry errors.

 

Authorization of transactions

 

Authorization schema

 

Accounting transactions typically follow the maker-checker concept. The transaction is entered or originated by one individual (the maker) and authorized by another individual (the checker). However, there are many transactions commonly put through in our accounting units, which require several or higher levels of authorization. Thus, while a draft is typically paid by the Assistant Manager in DAD, payment of a draft ex-advice typically requires the sanction of the Manager or AGM. Again, a cheque issued by a current account holder may be paid by the AM/Manager/AGM depending on the amount.

Each activity in IAS is categorized as a function (e.g. the account opening function, a batch entry function, a draft issued function). IAS provides the facility to configure, for each function, the number of levels of authorizations required and the facility to define the officers who are eligible to authorize the transaction at each level. Further, such configurations can also be defined in such a way that the authorization schema for a particular type of transaction is based on the amount of the transaction.

 

To illustrate let us take an example of two cheques issued by a customer – one to be paid by transfer and one for withdrawal of cash. Two separate functions are used to make payment on the cheque. In the first case, the payment of cheque may be authorized by an AM and, if the amount of the cheque exceeds an amount of (say) Rs 1 crore, the transaction will have to be additionally authorized by the Manager. If the cheque has been issued for cash withdrawal, it can be configured to require authorization by both the AM and AGM (for example) or can be configured to require only one level of authorization, but that one authorization has to be by the Manager. This feature of the IAS provides each office/department the flexibility to configure the authorization schema of the functions they use in accordance with the provisions of the Banking Department Manual, extant DGBA instructions and practices in that particular office/department. For example, the authorization schema for a DAD which has a hierarchy of AM, Manager and AGM will be very different from the schema of a DAD which does not have a sanctioned post of a Manager.

 

Exception Handling

 

Notwithstanding the authorization schema described above, a particular transaction may throw up exceptions which cannot be handled within the defined authorization schema as described above. For example, a small value current account debit

transaction would ordinarily be passed by an AM, but if the transaction resulted in a minimum balance breach, a higher level of authorization would be required. Again, putting through a transaction in an inoperative account, posting value dated transactions, forcing an overdraft into an account, making payment on a lapsed transaction (for e.g. a Sundry Deposits entry which has lapsed into the Commission Account), etc. are all exceptional situations which may require a higher level of authorization than is warranted by the authorization schema.

 

Such exceptions are handled in IAS through the “Forward” option which is available on each authorization screen. Each officer, at the time of authorizing a transaction, has the option of “forwarding” the transaction to a higher level officer if the officer is not entitled to handle the exception thrown up by the system. If the authorizer is the highest level authorizer configured for the transaction, then the system allows the officer the option of specifying the user id of the officer to which the transaction is sought to be forwarded. Otherwise, the transaction is routed to the next level of authorizers as defined in the schema.

 

This mechanism of exception handling enables automation of some parts of the work flow in DAD in the sense that such exceptions would otherwise be handled by the putting up office notes and taking the sanction of the appropriate authority to deal with the exception. The mechanism also provides a complete audit trail of such exceptions and the manner in which they were dealt enabling management and/or auditors to more easily detect instances of violations, frauds, etc.

 

Report Production

 

A wide set of functionalities have been provided for the generation of reports, the automation of the process of generation and dispatch to different locations under the IAS.

 

A large number of reports which are commonly required for the day-to-day operations of DAD, DGBA and other central office departments as well as the reports which are required at specified periodicities (e.g. weekly statements, fortnightly returns or annual closing statements) are generated by the IAS. In addition, any IAU can generate customized reports using Crystal Reports – a report writing software which provides a set of user friendly front end tools which can be used to generate any special purpose/new reports using the IAS database.

 

Report generated by the system can be directed to a various types of printers at local or remote destinations. These reports can also be sent electronically to remote destinations e.g. to central office, customers, other RBI offices, etc. without any user intervention, if they have been so configured. The system also provides the facilities of dispatching reports/advices through mail or through fax.

Certain kinds of reports – e.g. daily statement of accounts, balance confirmation statements, reminders of outstanding DDs, collection items, TRAs, etc. are configured to be automatically generated and dispatched at specified periodicity. The system provides the facility of enabling this in an automated fashion. Thus, a one time configuration of the system will ensure that balance confirmation statements for all or fax (depending on the customer profile) at (say) the end of the last working day of each month.

 

Another facility is to generate and store reports which can then be accessed and/or dispatched only by some authorized individuals. Thus, reports like the Weekly Statement of Affairs (which is required to be authenticated by the Head of the Banking Department) can be configured to be generated automatically at the Friday End of Day but will then be stored from where it can be sent to DGBA only after being viewed by the GM/DGM concerned.

 

Each report can be configured to print amounts in either Indian or International format depending upon the requirements of each report. For example, statement of accounts of foreign central banks may be required to be printed in international format.

 

Advices

 

Many transactions, especially customer transactions, are required to be advised to the concerned customers. Most common among such advices are the debit/credit advices sent to the Bank’s customers. Other examples include standing instruction execution advice, LC objection advice, advice for loans due for maturity, advice for insufficiency of collateral, etc.

IAS provides a facility whereby customer transactions can be automatically advised to the customer through SFMS message, e-mail or fax or the advice can be printed for manual delivery to the customer. The mode of transmission can be selected or can be configured to be based on the customer profile.

 

Each function can be configured to automatically generate and dispatch such customer advices on completion of each transaction. Alternately, when such automatic generation of customer advices is not desirable, advices can be configured not to be generated automatically. Advices can then be generated only on demand using an option on the transaction screen.

 

Charging of Transactions

 

At present, the Bank charges its customers for very few of the services it provides. In some cases like the issue of TTs, only the cost of the transmission is recovered. Internationally, however, most central banks do charge for the service they provide. The Federal Reserve System, for example, is required by law to fully recover costs of some of the services it provides especially in the payment systems area.

 

To take care of future requirements, where the Bank may also start charging for its services, provision has been made in the IAS for charging for various services provided by the Bank.

 

Charges in IAS can be broadly classified into two categories: RTGS charges and IAS charges.

 

In the RTGS system, charges are based on the events. Each significant item of work in the RTGS can be classified as an event which is recorded and logged in the system. Some examples of events are receipt of a payment transaction, settlement of the transaction, rejection of a transaction, invocation of gridlock resolution, settlement of an MNSB transaction, request transaction for IDL, etc.

 

For each event, different charges can be configured based on:

 

·         Timing of occurrence of the event

·         Transaction type associated with the event 

·         Amount of the transaction

 

Charges are recovered from the settlement account of participants at periodic intervals – the actual periodicity being configurable by the user.

 

In IAS, charges are associated with particular transactions both financial and non-financial. They can be configured to be recovered immediately on completion of an underlying transaction or can be accumulated to be recovered at defined intervals. There are different kinds of charges which may be recovered in IAS – charges for remittance transactions, charges for collection/purchase of instruments, charges for execution of standing instructions, commitment and processing charges for loans, charges for accounting transactions, etc.

 

The actual amount of the charge to be recovered with any transaction is defined in the system using charge codes. Each charge code defines the algorithm for calculation of the charge amount – either a flat amount or a percentage of the transaction amount or a combination of both. Charge codes can be configured to have different algorithms for different ranges of transaction amounts.

 

The Charge Codes will also be used to specify the account to which the charges should be credited. In fact, different credit accounts can be specified, for example one account for the flat amount of charge and one on the differential amount. Charge codes also define how the charges are recovered – immediately with the transaction (e.g. for remittance transactions) or at pre-defined intervals.

 

Keeping Open the Books of Accounts across business days;

 

Value Dating and Back Dating of transactions

 

The books of accounts of independent accounting units including DAD and DGBA are sometimes required to be kept open across dates to accommodate special transactions like some critical government or foreign exchange transactions. In DGBA, the whole host of activities comprising annual closing may spill over beyond 30^th June. Similarly, there could be other occasions where some critical transactions have to be accounted for as of a previous accounting date. However, the books of accounts for that day may have already been closed.

 

IAS provides several mechanisms for dealing with such situations and such transactions:

 

(a)   Value Dated transactions – Transactions can be put through on the current business day with a previous value date. The value date of the transaction is the date on which the balance in the account is affected by the transaction. The books of accounts will not be re-opened when a value dated transaction is put through; nor will the General Ledger balances be updated with effect from that date. Customer account statements will, however, show the value dated balance.

(b)   Back dated transactions – A back dated transaction is one which affects the General Ledger as of the previous date. Back dated transactions are accepted during the day but are processed only at the end of the day. General Balances and account balances are updated for all days beginning from the back value date to the current business date by re-opening the books of accounts for all intermediate dates. Various daily reports can be re-printed when back dated transactions are put through. The set of such reports to be re-printed can be selected by the concerned user.

(c)   Keeping books open across business days – The End of Day activity in any IAU comprises of a set of activities of which updating the General Ledger is one. In IAS, the function of the updating the General Ledger has been separated from the other end of day activities. When the books of accounts are required to be kept open, the end of the current business date is performed but the General Ledger is not updated. On the subsequent day(s), transactions for both the current day and the day(s) for which the books have been kept open can be put through. The GL update for all intervening days can then be done at a later date when all transactions have been completed.

(d)   Annual closing in DGBA – In DGBA, the annual closing function has also been segregated from normal EOD activities enabling DGBA to keep its books open across the year, if necessary. This provides DGBA the flexibility of continuing to account for transactions in the new financial year without completing the annual closing for the previous financial year.

 

The Central Office Transaction Account

 

The IAS introduces a new way of handling transactions between central office departments and DAD, Mumbai. The transactions between central office departments and DAD, Mumbai can be broadly classified into transactions which involve issue of payment orders by the central office departments and their payment by DAD, Mumbai, and other transactions.

Under the IAS, all payment orders issued by central office departments (both independent accounting units and other central office departments) will be issued by credit to the RBI General Account of Mumbai Office. The corresponding TRA will be sent electronically to DAD. The TRA will be responded in DAD and the proceeds parked in the Central Office Transaction (COT) account of the department issuing the instrument in a manner similar to advice noting for drafts. When the instrument is presented for payment, the details of the instrument are compared with the details of the instrument as provided by the issuing department and the instrument is paid by debit to the COT Account.

 

All other transaction between DAD and central office departments will be settled through the RBI General Account.

This method of settlement of transactions provides additional security for payment order transactions as instruments will be paid only after the issuing advice is noted. Further, other transactions will be subject to the reconciliation discipline of the RBI General Account.

 

Multilateral Net Settlement Systems

 

Multilateral Net Settlement Systems (MNSBs) are settlement batches received from net settlement clearing entities. Each batch comprises a set of transactions which debit or credit a set of accounts in IAS/RTGS.

 

MNSBs will be received in the IAS/RTGS system from the clearing houses, from the Clearing Corporation of India and from any other clearing entity permitted by the Bank to settle it’s clearing settlement across the books of DAD. All MNSBs will be processed by the RTGS system though the MNSB may affect both settlement and current accounts. The features provided in the system to handle MNSB transactions are as follows: 

 

·         Types of MNSBs handled: The system provides the facility for handling four types MNSBs viz. MNSB without any return clearing (e.g. Inter Bank clearing), MNSB with returns (e.g. MICR clearing), Guaranteed MNSBs (e.g. CCIL’s government securities and forex clearing) and MNSB with dishonor period (no clearing of this type is conducted at present in our country).

 

·         Provision for Limited purpose RTGS membership: The member of each MNSB batch must be defined as an RTGS participant. However, if the member is not otherwise a full participant of the RTGS system, then the system provides the facility of defining a limited purpose participant with no settlement account. The member must have an account in the IAS which will be used to settle the MNSB. The system also provides the capability of handling MNSB transactions affecting government accounts (e.g. the account of Director, General Post Office) or the RBI General Account (in Mumbai, RBI, Belapur functions as a distinct member of the clearing house and its net position in clearing is settled through the RBI General Account).

·         Un-cleared funds management: The RTGS system provides the facility of disallowing the use of un-cleared funds arising out of clearings with returns till the entire clearing cycle is complete. Each member who participates in a clearing which has returns or is associated with a dishonor period must have an un-cleared funds account in IAS. This account will not be a settlement account. All funds arising out of clearing, which are not clear funds, will be parked in this account (which could be a customer current account). However, the account holder will not be able to use these funds for making payments.

·         When the funds become clear, they are made available in the current account itself or transferred to the settlement account, as the case may be.

·         Handling of guaranteed MNSBs: Guaranteed MNSBs are those which have sponsorship arrangements in place to ensure that the MNSB is settled even if one or more members in a net debit position default in meeting their arrangements for different clearings – a list of sponsors, their respective sponsorship limits and the priority order in which their funds will be accessed to meet requirements for funds. The system will invoke the sponsorship arrangements, in case of need, automatically and no user intervention will be necessary.

·         Provision for time window for MNSB settlement: Given the crucial nature of MNSB transactions, the RTGS system provides for the definition of a time window within which the MNSB must be settled after being received in the RTGS system. If the MNSB fails to settle during the first attempt at settlement, then it will be re-tried at configured intervals of time within the defined time window. At the end of the time window, there will be no further automated re-tries to settle the MNSB and the MNSB can be canceled by a user from RBI. However, if considered desirable, subsequent settlement attempts of the MNSB can be manually invoked. The facilities of canceling a MNSB and of invoking a settlement attempt are available only to RBI and not to the clearing entity submitting the MNSB.

·         Rule 11 Processing: The RTGS system provides the facility for handling MNSB transactions which are cancelled (due to default by one or more participants in meeting their obligations) and have to be un-winded by the clearing house. Any un-cleared funds of the defaulted participants are parked in a separate Sundry Account and credited back to the participant only after the clearing cycle is complete.

·         Forcing of MNSB transactions: The RTGS system provides the capability of forcing the settlement of MNSB transactions to meet exigencies. Thus, MNSB transactions may be forced to settle even though the settlement may result in, for example, an overdraft in the account of one or more participants.

·         Provision for IDL for MNSB transactions: The system also provides the capability of using IDL generated funds to settle MNSB transactions. Each clearing type can be separately configured to be eligible for IDL. If eligible, then the system will send IDL request messages to SSS in case of insufficiency of funds in the settlement account of any member of the clearing type in a manner akin to IDL requests for other transactions.

 

 

The Securities Settlement System Interface

 

The functioning of the Public Debt Office is closely related to the functioning of DAD. PDO accesses the services of DAD for putting through all its funds related transactions, while DAD needs to interface with PDO for all activities requiring a transfer of securities. Further, the RTGS system relies very heavily on SSS to enable it to make intra day liquidity available to the RTGS participants. The Bank’s Rupee Investment Section in DGBA also relies on the Public Debt Office as the Bank’s substantial portfolio of investments in government securities are held in PDO.

 

The activities of the Public Debt Office are being computerized as part of the Securities Settlement System (SSS). A message based interface to the SSS has been built up as part of the IAS to ensure smooth interaction with SSS for various activities. The necessary functionalities to take care of the special requirements of SSS to put through funds transfers have also been built into the system.

 

The RTGS System uses the SSS interface to request for Intra Day Liquidity and its reversals. Whenever, a participant does not have sufficient funds in its settlement account to settle a transaction, RTGS sends a  message to SSS giving details of the participant and the amount of funds required subject, of course, to the participant being eligible for intra day liquidity and the required funds are within the IDL limit available for the participant. On receipt of the message, SSS checks whether sufficient securities to cover the funds required are available in the participant’s SGL account (typically an accounted designated for IDL) after applying the prescribed hair cuts. If so, then the securities are transferred to the Bank’s SGL account and a message is sent back to RTGS system indicating the actual amount of funds which can be released to the participant. On receipt of this message, RTGS credits the settlement account of the participant with the indicated amount and debits a loan account in IAS for an equivalent amount.

 

Whenever an IDL reversal is possible, RTGS first debits the settlement account of the participant and then sends a message to SSS to release the securities to the participant giving the reference of the earlier IDL request to enable SSS to identify the securities to be released.

 

At the end of the day, if any IDL has not been reversed, RTGS sends an “Un-reversed IDL Notification” to SSS to enable it to deal with the securities taken in lieu of the unreversed IDL.

 

The entire sequence of events described above takes place with zero user intervention both in the RTGS System and in SSS. At the end of the day, a SSS reconciliation report is printed giving details of un-responded messages and un-marked off reversal requests to enable manual reconciliation of differences, if any, between RTGS and SSS. IAS also interacts with SSS for the management of collateral and for investment in government securities on behalf of customers as described above.

 

SSS needs to interact with IAS/RTGS for various purposes, viz.

 

·         DVP transactions

·         MNSB batches of government securities clearing received from CCIL 

·         Auction of government securities 

·         Payment of interest on government securities held by current account holders

·         Payment of maturity proceeds of government securities held by current account holders

·         Open Market Operations

·         Liquidity Adjustment Facility auctions

 

For the first two of these purposes (DVP transactions and MNSB batches), SSS interacts with IFTP very much like any other participant or clearing entity interface. For the others, special purpose functions have been provided in IAS to enable the receipt of electronic messages from SSS, their processing, resultant debits/credits to current or settlement accounts and response to SSS. Where the Bank itself is a party to the transaction being originated by SSS, the RBI General Account of BRIS is operated and special TRA messages have been designed to take care of such messages to BRIS.

 

These transactions can also be received from SSS in paper form in which case data will have to be physically entered through special purpose transaction screens. When received electronically, these functions can be configured to process the SSS transactions without user intervention.

 

The functional components of the IAS and RTGS systems which need to interact with the Securities Settlement System normally expect the SSS to be available throughout the business day. However, in case SSS is not available or cannot be communicated with, the IAS system provides for contingency arrangements under which both RTGS and IAS can continue to function in a manner described below.

 

The RTGS system normally makes IDL available through intra day repos. However, intra day liquidity can also be provided through the use of collateralized funds transfers which do not require constant message flow between RTGS and IAS.

The Loans and Advances module interacts with the SSS system for transfer of securities through the exchange of electronic messages. However, in case of lack of online availability of SSS, provision for printing paper advices to SSS has been made in the system. These paper advices can be sent to the SSS and on receipt of paper confirmation of securities transfer, the underlying transaction can be “forced” in the IAS. In both cases, end of the day SSS reconciliation reports can be used to take care of any discrepancies between the data in the two systems.

 

APIs and the Generic File format for transaction upload

 

DAD is the accounting unit for the Bank’s regional offices and branches and maintains the books of accounts on behalf of all departments attached to the office/branch. DGBA also maintains the books of accounts on behalf of a set of central office departments which are not independent accounting units. Each of these departments needs to interact with DAD or DGBA as the case may be to put through their accounting transactions. Where these departments have their own independent systems, these systems need to interact with the accounting systems in DAD/DGBA.

 

IAS provides two mechanisms through which transactions originated in various departments can be accounted for in DAD or DGBA.  These are Application Protocol Interfaces (APIs) and a generic file format for uploading transaction data.

The APIs can be used by systems in other departments to directly access accounts in IAS and post transactions in these accounts. The transactions sent to IAS through the APIs are processed in IAS without any user intervention. The APIs enable various kinds of transactions like RBI General Account transactions, transactions in the sundry deposits and suspense accounts, payment order transactions and cheque related transactions to be put through in addition to transactions in internal accounts. The details of the officers authorizing the transaction in the originating department must mandatorily be communicated to IAS where they are stored for the purpose of record and audit. The security of the data received through the APIs is ensured using the PKI infrastructure.

 

For departments which are unable to access the accounts in IAS through APIs or need to put through a large number of related transactions can send their transactions to IAS in a file in a pre-defined format. The transactions received in the file can be uploaded in the IAS system precluding the need for manually posting these transactions. These transactions will, however, need to be separately authorized in the system.

 

A generic format has been defined for accepting transactions from other departments in a file. The structure of the generic file format is similar to the structure of the API and enables the reporting of various kinds of transactions to IAS.

 

CFMS Interface

 

The IAS provides an interface to CFMS which provides the following special features:

 

·         Interface to all customer accounts in DAD (both current and settlement accounts) to CFMS to enable CFMS to maintain an up to date picture of the transactions and balances in the various customer accounts.

·         An optional Interface to all internal accounts in DAD and in the central office departments to enable reporting of transactions and balances in the various internal accounts to CFMS. This can enable CFMS to maintain a centralized picture of the position in various internal accounts which can be accessed by controlling central office departments.

·         Facility to receive and process funds transfer requests from CFMS in a STP manner without any user intervention.

·         Facility to transfer funds to/from settlement accounts through an interface to the RTGS system in addition to transfer of funds to/from current accounts.

 

Archiving Facilities

 

The Total Solution comprises of a number of diverse system components viz. IAS, RTGS, IFTP, PI, SCARS and DMS, each maintaining its own current and historic view of data in a dedicated database. Certain types of data are voluminous (e.g. transaction data) and the size of the database would grow continuously unless obsolete data is removed.

The system provides a full set of tools to archive data in a meaningful manner in order to ensure that the size of the database kept “online” does not become un-manageably large and also that the archived data can be easily and intelligibly retrieved.

 

The system components residing in the S/390 system (IAS, RTGS and IFTP) are equipped to handle two kinds of databases – the On Line database and the On Line Archive database. The data available on-line is partitioned in this way to allow transactional operations to be performed on a minimal data set of ‘current’ data, whilst historical reports and enquiries can be performed on larger on-line ‘aged’ data sets without impacting the live system.

In addition, the system provides the facilities for maintaining archived data in offline storage devices such an Write Once Read Many (WORM) devices. The data resident in those components of the system not residing on the S/390 system can also be archived into such devices.

 

The process of data archival is automated and does not require user intervention except to the extent that off line devices may have to be loaded into their reader/writer machines. For this purpose, the system provides a flexible system of defining the manner and the parameters based on which data in the system becomes eligible for archiving – both for the online archive and the offline archive.

 

The archival period for each kind of data is based on firstly, the finality criteria for that type of data and secondly, for the configured retention period for retention in the on line database and in the on line archive database.

 

The finality criteria of data defines the point at which the data ceases to be “current”. Thus, transaction final is complete when the business day is completed whereas data pertaining to an entry in the Sundry Deposits Account is considered to be final only when the entry is fully reversed and the data pertaining to a loan is final only when the loan is completely repaid and all dues on account of the loan have been recovered. The system also provides the facility to configure when data is to be archived i.e. the frequency of archival can be configured. On the archival data, al data which is eligible for archiving will be archived.

 

The system also provides facilities for generating reports and enquiries from archived data – data from both online archive databases and offline archived databases (after the data is reloaded into a temporary database).

 

Chapter VI

 

Superior Security Features

 

The various superior security features of the proposed Real Time Gross Settlement Systems are as follows:

1.     Various cryptographic services are available in the various components of the RTGS system in two forms Crypto Server and Crypto Subsystem. In case of Crypto Server these services will be running on dedicated Windows 2000 platform. But, in case of Crypto Subsystem, the entire Cryptographic system will be co-located with the other application software. The various crypto graphic services are :

·         Signing  and Encryption of hash.

·         Decryption and Verification of hash.

·         Signing  of message.

·         Verification of message.

·         Fetch the latest CRL from the LDAP server at IDRBT. 

·         Fetch certificates listed in the LDAP Server at IDRBT.

2.     Hardware Security Module (HSM) or Smart Card will be used for secure storage and manipulation of private keys.

3.     The primary and the backup system of the RBI will be configured with multiple standby Cryptoservers, each with one or multiple HSMs for the purpose of disaster Recovery. Both the primary and secondary set of Cryptoserves have the same set of private keys duplicated on their HSMs.

4.     The Crypto Tool is a support tool for the cryptographic services and is installed along with either a CryptoSubsystem or a CryptoServer. The Crypto Tool provides offline services related to asymmetric keys, certificates, backup of private keys, Changing SmartCard PINs, Displaying Smart Cards Contents, Displaying Certificates and Performing LDAP CRL/Certificate fetches. The Crypto Tool will be provided as a support tool for the Cryptographic Services.

5.     The facility of Crypto Tool will be available at PI, IFTP, IAS-UI and various Command and Control terminals.

6.     Every Participant interface will have to install this Crypto Tool to generate and maintain private keys and certificates. Access to which is restricted to the System Administrator.

7.     The Various function which Crypto Tool  supports are as follows:

 

·         Generate RSA Key Pair.

·         Generate Certificate Request. 

·         Import Private Key.

·         Import certificate.

·         Creation of Private key Backup 

·         Request CRL.

·         Pre-Load / fetch Certificate Set.

·         Invalidate a Certificate / key Pair.

·         Blank SmartCard / HSM.

·         Display Certificate Details. 

·         Change PIN.

·         Display SmartCard/HSM Contents. 

·         Display Cache.

·         Display CRL.

·         Install CA Certificate.

 

The User Control Tool will provide various functionalities to configure the access and function availability to the workstation-users of the PI, Crypto Tool and various Command and Controls Terminals.

 

Chapter VII

Role and Responsibilities of the Central Bank and Participants (Indicative only)

 

Central Bank :

 

I. The central bank should clearly define its payment system objectives and should disclose publicly its role and major policies with respect to systemically important payment systems.

 

I.1 Designers and operators of private sector payment systems, and participants and users of all systems, as well as other interested parties, need to have a clear understanding of the central bank’s role, responsibilities and objectives in relation to payment systems. They need also to understand how the central bank intends to achieve those objectives, whether by formal powers or other means. This will enable those parties to operate in a predictable environment and to act in a manner that is consistent with those objectives and policies.

I.2 The central bank should therefore have clear payment system objectives. It should also define clearly and disclose major policies that will affect the operators and users of systems to ensure that they are well understood and to build support for them.

 

II. The central bank should ensure that the systems it operates comply with the core principles.

 

II.1 The central bank is often the operator of one or more systemically important payment systems. It, therefore, can and should ensure that they comply with the core principles.

 

III. The central bank should oversee compliance with the core principles by systems it does not operate and it should have the ability to carry out this oversight.

 

III.1 where systemically important payment systems are not operated by the central bank, it should oversee their compliance with the core principles. The central bank’s oversight of systems should have a sound basis. There may be a wide variety of means by which this can be achieved, depending on the country’s legal and institutional framework. Some countries have a statute-based system of oversight with specific tasks, responsibilities and powers, assigned to the central bank and sometimes also to other agencies. Others have regimes based on custom and practice, which rely on non-statutory approaches. Either approach can work in its own setting – depending on the legal and institutional framework of the country concerned and the acceptance of the approach by the institutions overseen. The potential benefits of a statute-based approach to oversight, however, deserve serious consideration in countries newly establishing or significantly revising the oversight role and related policies.

 

III.2 The central bank should ensure that it has the expertise and resources to carry out its oversight functions effectively. It should not use its oversight role to disadvantage private sector systems relative to those which it owns and operates itself, but to ensure that the combination of public and private sector provision meets the public policy objectives.

 

IV. The central bank, in promoting payment system safety and efficiency through the core principles, should cooperate with other central banks and with any other relevant domestic or foreign authorities.

 

IV.1 A number of different authorities can have an interest in the safe and efficient functioning of payment systems. In addition to central banks, they can include, for example, legislative authorities, ministries of finance, supervisors and competition authorities. In particular, oversight of a country’s payment systems, surveillance of its financial markets and supervision of financial institutions are complementary activities, which may be carried out by different agencies. A cooperative approach is likely to assist the fulfillment of all the relevant public policy goals.

 

IV.2 Payment system oversight concentrates on the stability of the system as a whole, while the supervisors of individual banks and other financial institutions focus on the risks to specific participants. In particular, in assessing payment system risks, overseers may need to take into account the ability of individual participants to fulfill their responsibilities in the system. In monitoring the financial risks for an individual institution, the supervisors may need to take into account risks to which participants can be exposed as a result of participation in the systems and which could affect the viability of the institution. Regular exchanges of views and information between the supervisors and overseers, including, where relevant, about key individual participants, can assist these complementary objectives. These exchanges can often benefit from agreements on the sharing of information.

 

IV.3 Cooperation is particularly important for systems with cross-border or multi-currency characteristics. The principles for cooperative central bank oversight set out in Part D of the Lamfalussy Report provide a framework for such cooperation.

 

Participants :

 

·         The delivery of the products and services need extensive use of information technology necessitating high magnitude of investment. However, with a view to enhancing the quality of customer service as also to enhance the quality of control, one of the prime thrust areas for the future would be the completion of branch computerisation and networking of banks. This would also necessitate putting in place of the appropriate legal and security systems.

·         Technology has demonstrated potential to change methods of marketing, advertising, designing, pricing and distributing financial products and services and cost savings in the form of an electronic, self-service product-delivery channel. These challenges call for a new, more dynamic, aggressive and challenging work culture to meet the demands of customer relationships, product differentiation, brand values, reputation, corporate governance and regulatory prescriptions.

·         The imperative need would be to inculcate an attitudinal change in the mindset of bankers – towards providing services through such innovative, simple and secure means.

 

·         The participants will also, however, address various initiatives/projects in terms of the following requirements:

 

·         Institutional arrangements

·         Type of instruments or messages

·         Process and Procedure re-engineering

·         Project Implementation Schedule

·         Change Management 

·         Investment costs and recurring expenditure

·         Legal, regulatory framework and oversight issues 

·         Risk Management and control measures 

·         Benefits projection

·         Macro-economic impact

 

List of References

 

·         Real-Time Gross Settlement Systems, Report prepared by the Committee on Payment and Settlement Systems of the central banks of the Group of Ten countries, March 1997

·         ‘Clearing and Settlement Systems for Securities – World Bank Discussion Papers 321’, Jeff Stehm, The World Bank, Washington DC.

·         ‘The Architecture of RTGS system’, Christian Vital.

·         ‘Inaugural address by Shri V. Kamesam, DG, RBI at the conference of CMDS public sector banks at IDRBT, Hyderabad on November 2,2001”.

·         ‘Payment Systems in India – Review and Recommendations”, RBI, October 1998.

·         ‘Report of the Advisory Group on “Payment and Settlement System” released, RBI, July 16, 2001.

·         Report  on Technology Upgradation in Banking Sector,(Vasudevan Committee), 1999 

·         Core Principles for Systematically Important Payment Systems, Committee on Payment and Settlement Systems, BIS, January, 2001

·         Controlling Specification for the Total Solution for the RTGS System