Chapter Twenty Five

Treasury Systems

TREASURY SYSTEMS TOOK their baby steps with the advent of computing, and banks, for which Treasury is a core and critical function, led the way with automation and management of balance sheet and liquidity. The emergence of markets, asset classes, and market risk increased the rate of automation of processes and bookkeeping, leading to today’s world of interconnected system environments that span a multitude of purposes, environments, and budgets.

This chapter provides an overview of what Treasury systems are, how the entire system universe is connected, and how the benefits accruing from a system implementation can be assessed. We end with a process and checklist that you can adapt to suit your needs while doing your own system assessment and implementation.

TREASURY MANAGEMENT SYSTEM BACKGROUND

Treasury systems have evolved over time, use, and the corresponding growth of global markets and their complexity. While there is a cost and maintenance resource impact (as is the case for every system), more often than not, a good system implementation has far-reaching efficiency effects for Treasury and hence the corporation as a whole.

Why Do We Need a System?

The topic of why we need a system may sound generic and clichéd, but we would like to discuss this important aspect at the outset. It is important because it feeds into the final impact: better financials. The success of any project, including system implementations, is to achieve efficiency and hence financial benefits for the firm. A system implementation (or nonimplementation) decision is successful only if it results directly and indirectly in the firm’s improved financial performance.

Hence, we present some of the key process wins of a good system implementation that result in tangible improvements in the firm’s financial performance. Figure 25.1 depicts some benefits of establishing a good system.

FIGURE 25.1 Financial Impact of Good System Establishment

What Is a Treasury System, and How Does It Fit into the System Universe?

The world of the Treasurer is becoming increasingly dependent on technology and the processes and information flows that are based on technology. Figure 25.2 provides an idea of the firm’s systems universe, which works off a centralised Treasury and distributed centres at the country and subsidiary level that also have their own systems and linkages. The elements may exist under one single Treasury management system (TMS) or may be distributed by their systems functionality expertise.

FIGURE 25.2 System Environment and Interfaces

The TMS helps the Treasury function in processing and supporting processes with some or all of these broad functionalities:

• Banking
• Balance sheet and capital
• Markets and risk
• Cash flow
• Deal entry
• Back office (operations)
• Middle office (process and control)
• Cash flow and forecasting
• Analytics

The TMS is usually linked with the general ledger (GL) system or enterprise resource planning (ERP) of the organisation and also has linkages with other systems in the firm’s universe. Figure 25.3 is a pictorial summary of some of the TMS-related information flows and linkages. The three key themes of risk management, accounts and cash, and value-add are only one way to represent or classify the various roles and processes.

FIGURE 25.3 TMS Linkages and Information Flows

What Important Characteristics of a System Do We Need to Know?

Some of the key characteristics of a TMS, and hence considerations for selecting the most appropriate one for a firm, are depicted in Figure 25.4 and outlined next.

FIGURE 25.4 Characteristics of a TMS

Functionality

The functionality of the TMS denotes the various capabilities of the system and would be a direct relationship to the actual processes and activities of the Treasury. Broadly, these would be:

• Balance sheet and capital. Debt and capital management, inter-company cost of capital, working capital (WC), accounts receivable (AR) and accounts payable (AP) management, debt and capital-related payments, investments tracking and monitoring
• Markets and risk. Risk limits, measurement, tracking and booking, maturities
• Cash and liquidity. Cash flow analysis, forecasting, collections and payments management, reconciliation, in-house banking, funds transfers, and bank interfaces
• Accounting entries. Transaction entries, data entry and interface, accounting entries
• Back office. Transaction processing, tracking, and settlement
• Middle office. Control, monitoring, model validation, limit and position verification, mark-to-market data, reconciliation
• Analytics and reporting. Supporting each business unit for its analytics and reporting, providing automated and objective evaluation and benchmarking results

Technology

The infrastructure and use of technology is the second key characteristic of the TMS. The good thing about technology is that one can be a great user of technology without being a technical expert. Here we attempt to simplify and translate some of the concepts and terms to enable readers to make well-informed and rational decisions on their own on which technology solutions to implement.

• Platform. The platform is a combination of the hardware architecture and the software framework used to run the applications on the hardware. It also includes decisions around the kind of databases used, the front end and the choice of client (what you see and access the system through, the front end) and server (the back end that is the backbone of the system). The vendor should provide you with a detailed list of advantages and disadvantages of each. One important aspect to bear in mind is the ability to upgrade or sustain a particular platform—will this last for the next few years?
• Delivery method (hosting and ownership). The delivery method indicates how the system reaches the user—where it is physically located (hosting) and who owns it (ownership). Depending on the number of locations, complexity of data, and locational bandwidth availability and cost, the reader can determine which method would work best for them. Vendors typically have a preferred delivery method and, depending on requirements and budgets, will be able to offer a suitable solution to match user needs. Some alternatives are given next.
  • Software as a service (SaaS). Software and data are resident at the vendor’s servers and accessed by users through a browser or simple application at their end. SaaS uses the application services provider (ASP) model.
  • Cloud computing. The software and data are stored on servers on the Internet, with the users being agnostic to exactly where the data are located. This method provides the vendor with more flexibility on computing power and storage, which could result in continuous improvement to user response times and cost structure.
  • On premises. The system resides on hardware and servers at users’ sites.
  • Software-plus services (S+S). This method combines on-premises solutions with cloud computing to intelligently enhance the user experience and provide cost and performance efficiency.
• Specialisation. Many service providers, such as banks, brokers, information service providers (such as Thomson Reuters), accounting firms, and consultants, offer some components of a TMS to their clients. In many cases, these can be integrated with existing systems to provide a good experience, depending on the specialisation. Some ERP systems also have Treasury modules that have good capabilities. Many technology firms also offer specialised stand-alone TMS solutions. Users can make appropriate decisions depending on their existing system establishment and needs.
• Development and customisation. The decision on whether to customise systen development or use an existing system is a critical decision with long term impact. For many needs, using an available system might prove to be a more effective method. Customisation involves effort, time, cost, and the chances of error owing to the tinkering around with a tried-and-tested system.
• Open standards. If the TMS uses open source development software, the costs could be significantly lower. Many TMS systems, however, work off proprietary technology.
• Security. Information security is a critical aspect, usually closely tied in with the hosting solution and the firm’s existing information security standards. Firewalls, virus protection, data integrity, and security form some of the components of this characteristic.

Interface, Integration, and Connectivity

How the TMS connects with the outside world, how it merges with existing systems, and how users can access it form some of the strongest differentiators among different systems.

• Interface. The interface of the TMS with various systems, such as payment gateways, electronic banking (EB), and ERP is a critical aspect. Some considerations here involve whether this interface is online or with delays, batch processed or real time, or encrypted.
• Integration. Integration involves connecting with some of the critical internal and external systems that are part of the environment, such as the ERP and EB platforms. For example, it can involve:
  • ERP integration
  • Payments
  • Collections
  • Inter-company account booking
  • Reconciliation
  • Bank account management
  • Payables and AP
  • Receivables and AR
  • Supply chain management
  • Entry automation
  • Accruals and cash movements
  • Data flow
  • Reporting
  • Bank reconciliation, cheques, deposits, cash balances
  • Registers of vendors, customers, and transactions
  • Processing
  • Posting transactions to the general ledger
  • Automatic reconciliation
• Connectivity. Access to the system, through specific applications or even the mobile phone, is an important determinant. Also, reporting and control elements become critical.

Vendor Service and Support

The technology partner or systems vendor plays one of the most critical roles in a system implementation, and the selection process must be well thought out and with the long term in mind. Some of the points for consideration are:

• Background. The vendor’s past performance, success record, and level of expertise are good measures, especially when comparing across vendors. The vendor’s own financial stability becomes critical to determine its staying power and longevity.
• Geographical spread. Geographical spread and availability of the vendor in the areas of implementation becomes more important, the more complex the requirements.
• Customisation. The lesser the need for customisation required in the system to meet client requirements, the greater the chances of system stability.
• Partnership. The degree of the vendor’s participation in meeting requirements and long-term vision as envisioned by the pricing and contracting must be considered.
• Outsourcing. The ability of the vendor to take on activities either immediately or over a period of time (to allow for opportunities and flexibility to outsource should the time come) also must be considered.

Costs and Benefits

Some of the cost and benefit aspects to be considered in the system decision are:

• Up-front costs.
• Maintenance costs. These include running costs and maintenance costs on an ongoing basis; includes hardware support, bandwidth, software licence, and per-user fees.
• Hidden costs. Incremental storage and bandwidth expenses, licence fee for non-TMS support (e.g., database, etc.).
• Efficiency saves.
• Resource saves. Reduction in the number of full-time employees.
• Turnaround times.

Maintenance

Once the system has been implemented, life begins. The day-to-day as well as long term running of the system will require resources and will have an impact on the functioning of the company. Some of the aspects to be considered for the maintenance of the system include:

• People requirement
• Backup
• Contingency and continuity
• Control
• Regulatory
• Accounting
• Ongoing development

SOME SYSTEM-RELATED QUESTIONS

Some questions always arise when talking about systems and their implementation. The next two questions are critical ones to ask, and answers are subjective, depending on the user’s experience levels. The views given here are mine only and might not fit readers’ specific situations:

• Should we change processes to use the new system or amend/customise the new system to fit existing processes?

• Should we aim for fantastic utilisation of normal systems or normal utilisation of fantastic systems?

TMS ESTABLISHMENT PROCESS

A simple 10-step process for TMS establishment is discussed next and depicted in Figure 25.5. Note that the process will vary in actual implementation from company to company.

FIGURE 25.5 TMS Establishment Process

Project Team and Tool Creation

The project team that will decide on the system and assist in taking the project through to closure should be comprised of key players who would be direct or indirect beneficiaries of the systems. A simple team structure is presented in Figure 25.6.

FIGURE 25.6 TMS Project Team Composition

It is important to have members across functions, led by the project manager, who should be a Treasury team member with a good end-to-end understanding of the working of Treasury. Inclusion of members from other functions are optional, depending on the complexity of the operation. Some Treasurers insist on representation of all functions in the team—the need to be on the team will also drive contribution and enthusiasm from the team members, and prudence is advised in deciding the representation.

The responsibility of this team officially ends with the selection of the TMS, with the team composition changing slightly when the implementation team takes over. For reasons of continuity, it is preferable to have the same members on both teams.

Needs Analysis

The needs analysis part of the process seeks to establish the key requirements going into the request for information (RFI) stage. The checklist provided could be one of the reference elements to consider, using the key characteristics of a TMS. Some of the critical aspects that need to be focused on include:

• The current system environment and automation levels, including ERP/GL system and other entities.
• Which processes to automate. Is the system replacing an existing one, or is it a completely new automation? Which processes and activities are being replaced or made more efficient by the proposed implementation?

Broad System ID

A scan of systems available as well as decisions on implementation and approximate budgets for implementation with available systems is obtained at this stage, which enables smooth preparation of the business case. A long list of vendors should be created based on the information gathered.

Business Case—Milestone I

The first milestone is reached while preparing the business case and obtaining management approval for the project. This stage quantifies some of the gains established on potential saves and efficiency increases, along with reduction in opportunities for operational losses and control lapses. Both initial and annualised estimates of saves need to be dimensioned. The parameters provided in Figure 25.1 could be a good starting point. The dimensioning of the costs would also provide an approximate indication of the maximum or break-even cost for system implementation.

The business case typically should be approved by the management team comprised of the chief executive officer, the chief financial officer, and perhaps a business head.

Management approval, apart from obtaining the official sanction and budget for going ahead, is a good test of the understanding and comprehensiveness of the team’s work thus far. Queries from management provide perspectives and depth that increase the robustness of the requirements and capabilities that the system is expected to provide.

Request for Information—Milestone II

The RFI is the first milestone in the process of implementation. The objective of the RFI is to identify the various vendors and get information from them to create a short list for the request for proposal (RFP), apart from ensuring that the list of capabilities that you are seeking from the TMS covers everything relevant.

The vendors from the long list should be contacted and briefed with further details that would help short-list them for the RFP. Some aspects to be remembered here are:

• Provide enough information to help vendors show their broad understanding of a solution, but not so much that you give the vendor little opportunity to display its own intelligence and creativity.
• Encourage vendors to provide their own value and points that they think would be applicable for your firm. Remember, this practice will help you enhance your own requirements list and perhaps trigger some aspect that might be important for your setup that you had missed.

Request for Proposal

Once the inputs from the RFI stage have been incorporated, the list of requirements and the final RFP template can be frozen. The vendors to be short-listed are decided on, and the selected vendors are approached for the final stage of selection.

The short-listed vendors should preferably deliver a presentation at the client’s office, with a demonstration of the system and its capabilities. If possible, guest IDs on a dummy or trial system should also be provided so that team members can access the system on their own time and explore its capabilities. Vendors should be encouraged to provide as much relevant information as possible for you to make the decision but not to overload you with too much information.

The following note highlights the importance of the much used “references,” which could degenerate into a routine form-filling exercise.

Selection—Milestone III

The selection process and the decision of the vendor mark the third milestone, and the most critical one. One approach would be to weight the criteria and then score each vendor across all the weights. If all team members are providing scoring inputs, the top and the bottom score for each criterion could be removed prior to computing the average.

The checklist only provides a numerical number. You must also factor in the overall approach, tenor, and subjective aspect of the firm’s own experiences and relationship with the vendor and attempt to quantify and make transparent and auditable as much of the process as possible.

If more than one vendor finishes in the top position or close to the top score, all vendors near that score deserve a second look. The cost element is important but should not be the only basis on which a vendor is chosen.

Implementation and Integration

Once the vendor has been decided on, it is time to implement the TMS. We categorise integration along with implementation, since the system needs to be integrated into the firm’s processes and existing systems and environment.

A team, which could be a derivative of the selection team, must be formed. The addition of members from the vendor side who have fixed responsibilities enables the transition process to proceed smoothly.

Representatives from some of the functions need to be involved primarily at the testing phase. Figure 25.7 shows the sample composition of an implementation and integration team.

FIGURE 25.7 Implementation and Integration Team Composition

The implementation and integration process is to be managed with rigor using project management tools and tracking methodologies. A typical stage-wise and time-wise plan is given in Figure 25.8.

FIGURE 25.8 Project Stages for Implementation and Integration

The planning stage lays out the timetable and responsibilities.

The second stage (Specifications [Spec] and Data ID) outlines the specifications and identifies the data elements that need to be captured. This sounds like a simple activity, but adequate attention paid to this stage would reduce the rework and further development that sometimes accompany a system implementation. Figure 25.9 lists some of the data points that can be captured during this stage.

FIGURE 25.9 Data ID Types, Spec and Planning Stages

The specifications are primarily divided into:

• User specifications, derived from the contents of the RFP document
• Functional specifications, consisting of the vendor’s understanding and articulation of the functionalities
• System specifications, which are the architecture and environment of the proposed system

Once the specification and data ID stage is completed, the vendor provides a more specific cost estimate with deadlines, which you might have to negotiate on.

The next stage is the system building stage, which is the core activity. It includes adapting an existing system or creating code for a new system and integrating with existing systems.

The training stage follows. It distinguishes the various roles that each team member will play and customises the training to their needs. For example, training for information technology (IT) and technology team members could focus more on the technology, maintenance, and information security administrator aspects; training for the financial control team could focus on the AR/AP aspects; and training for dealers could focus on the market aspects.

The testing stage involves drawing out detailed plans and expected results for user acceptance testing (UAT). Possible functionality-based beta testing could be done prior to the system being delivered for the UAT. Once the system has been handed over for UAT, it moves into the control environment, where every change, every version, or every release is controlled and recorded. The members of the team doing the UAT must have a list of expected results and compare the expected results with the actual ones. They must document the variances and agree with the vendor on the variances. If a particular functionality is found to be missing and has not been documented as part of user functionality, it can be classified as a new requirement and can have billing and cost implications. The cost and time estimates of the reworked aspects have to be reviewed and criticality established. Good practice is to consolidate the errors on a daily basis and evaluate criticality. Critical elements missing or not working would lead to immediate action to rectify.

The review process can start once testing is under way and continues once the sign-off has happened on the system. After the sign-off, the system, under a controlled environment, is handed over to the vendor for implementation and integration on actual systems.

Based on our experience, we believe that doing a parallel run before going live can help sort out some of the teething issues that typically occur during a launch. The parallel run helps to slowly integrate the processes and systems into the mainstream, with the ability to pull back should some large issue occur.

Review and Evaluation—KPI/Milestone IV

It is important to evaluate and measure the success of the system implementation. Key performance indicators (KPIs) should be established (usually early in the process) and used to test system effectiveness and utility. The KPIs should be measurable and quantifiable. This review and evaluation is the final project milestone.

Maintenance

Ongoing management of the system, periodic reviews, and managing the vendor is an ongoing process. It can be adequately managed by the Treasury function with the support of the IT function.

DEVELOPMENTS AND STANDARDS

Many changes are happening in the world of financial technology, and much of it is based on dramatic improvements in communication, connectivity, and messaging. One of these improvements, very pertinent to the Treasury professional, is the International Standards Organization (ISO) 20022 financial messaging standard and the Common Global Implementation (CGI). We present a short note on the CGI in the book and provide a summary of Industrial Products and Service Category standards in online Appendix D of this book (www.wiley.com/go/treasuryhandbook).

CGI: ISO 20022 on the Mainline

Synopsis

As corporates seek to reduce costs and mitigate risk, they are struggling to manage their relationships with multiple banking partners. As such, they are increasingly looking for multi-bank, multi-payment types and multi-country solutions. SWIFT’s creation of a universal financial messaging system is a key element supporting this trend and together with the ISO 20022 financial messaging standard and the Common Global Implementation or CGI are driving the underlying global market practice.

What exactly is CGI? The first thoughts of those involved in the financial sector might be towards a well-known provider of IT outsourcing services. Others may think of computer-generated imagery or common gateway interface, or perhaps even the Clinton Global Initiative. It is time now to brace ourselves for a new and innovative interpretation of a popular acronym in the world of financial messaging. The Common Global Implementation embodies the notion that, “A corporate can use the same message structure (for each message type) to interact with all of their transaction banks across the globe for payments initiation (credit transfer and direct debit), account and status reporting.”

Multi-Bank Factor

CGI is being driven by bank customer demand for multi-bank coordination of implementations where the projects are often characterised by:

Commitment of a global corporate, multi-banked, multi-payment types, multi-country implementations (mixed payables)

Direct involvement of multiple participating banks that may wish to individually offer additional value-added services

Active engagement as a corporate-bank partnership; and

Global or regional roll-out that may involve customer’s consolidation of internal payment infrastructures, for example through a payment factory platform.

Large corporates, more often than not, have multiple bank relationships, a trend that has grown in the wake of the global financial crisis as companies seek to mitigate risk, to reduce cost, and to obviate the need to “put too many eggs in one basket.” Managing multiple bank interfaces can be quite a challenge, particularly if different channels, different protocols, different formats, and different data requirements need to be factored into the implementation process. In some cases, management and maintenance overheads are costly and onerous and become amplified when they are proprietary.

CGI seeks to redress the multiplier effect inherent in managing the interfaces for multi-bank implementations (see Figure 25.10), through the use of the universal financial industry message scheme ISO 20022 as the base message standard and a corresponding message implementation template as the single harmonised format.

FIGURE 25.10 Multi-Bank Communication

ISO 20022

The International Organization for Standardization (ISO) is the world’s largest developer and publisher of international standards, formed through a network of national standards organisations from 162 countries. ISO 20022 is one such standard promulgated by ISO. It is a free and open standard.

ISO 20022 has been aptly described as a recipe for making financial messaging standards. The ISO 20022 methodology provides a systematic means to define and describe financial business interactions and a discipline to create the underlying messages that support the exchange of information in a structured format among the players involved in those processes. However, such exchanges will only work when both the sender and recipient can fully interpret and understand the message contents. Furthermore, the concept of straight-through processing (STP) depends on the automated exchange of precise and unambiguous information. The ISO 20022 standards go a long way towards making all of this possible and practical.

ISO 20022 in itself grew out of the need to attain convergence across numerous overlapping standardisation initiatives that were looking at XML financial messages. It was built on the work of an earlier standard, ISO 15022, a syntax used for the developing securities messages. In the payments world, it brought together four organisations involved in the development of messages for the financial industry: IFX, SWIFT, TWIST, and OAGI. Known as the ISTH, it sought to use ISO 20022 and the XML syntax as the new messaging approach.

XML has firmly established itself as a ubiquitous means of formatting data and has gained wide acceptance as the basis for data storage and data exchange in all areas of data processing.

ISO 20022 has progressively gained momentum and its impact on the financial messaging landscape is increasing—in total, some 300 messages at various stages of use. Since 2006, ISO 20022 messages have been published for the entire end-to-end payments chain, covering the corporate-to-bank payment initiation, bank-to-bank payment clearing and settlement, and bank-to-corporate account and status reporting. For payments, ISO 20022 adoption gained impetus from it being the format of choice for the Single Euro Payments Area (SEPA) in seeking to replace domestic retail credit transfers and direct debits with standardised European payments based on ISO 20022 messages. Real-time gross settlement (RTGS) systems and low-value payments systems around the world have also shown increasing interest in adopting ISO 20022 (for example, the Zengin System in Japan and the International Payments Framework), while others are focusing on building alignment with the standard.

The ISO 20022 payments messages have, for example, enabled the ability to capture remittance information and pertinent commercial data along with payment information, the use of multi-byte characters, enhanced references, and reporting of interest and charges.

It should be noted that in many respects the real business value of ISO 20022 lies in the support it gives to collaboration, allowing the financial industry and adjoined stakeholders to openly agree and align global business requirements in a uniform and standardised way. This has certainly been the case in the payments arena through the ISO 20022 Standards Evaluation Group (SEG), the Payments Market Practice Group (PMPG) and, more recently, the CGI.

ISO 20022 represents the next generation messaging standard for SWIFT.

CGI

While the ISO 20022 payments message definitions in themselves provide a comprehensive basis for data exchange, they have also led to mapping variations and differences in how the messages are implemented. The design of the payment messages caters for a range of payment initiation (credit transfer and direct debit) instrument types, methods, and reporting requirements. There are hundreds of elements (for example, over 1,300 in the Credit Transfer—pain.001.001.03), most elements are optional and external code sets often shared across different message types. Consequently, implementation inconsistencies were encountered across different financial institutions, in particular highlighted by large corporates embarking on multi-bank implementations.

The CGI was designed specifically to address these inconsistencies. Created in October 2009, CGI currently includes 50 registered members, of which 36 are contributing members. It is an ad hoc, voluntary forum that is open (without membership fees) to organisations that have a common interest in collaboration, promotion, and adoption of the ISO 20022 XML financial message set.

The goal of CGI is to provide this forum for both financial (banks and bank associations) and non-financial institutions (corporates, corporate associations, vendors, and market infrastructures) to progress various corporate-to-bank implementation topics on the use of ISO 20022 messages and to other related activities in the payments domain. In particular, it is to simplify implementation for corporate users and thereby promote wider acceptance of ISO 20022 as the common XML standard used between corporates and banks.

The CGI goal is being achieved through consultation, collaboration, and agreement amongst all players on a series of common implementation templates for relevant ISO 20022 financial messages, leading to their subsequent publication and promotion in order to attain widespread recognition and adoption. The high level of collaboration that has been attained among the major banks is significant to achieving global coherence with their respective implementations.

To date, six implementation templates have been released:

Customer Credit Transfer Initiation (pain.001.001.03)

Customer Direct Debit (pain.008.001.02)

Customer Payment Status Report (pain.002.001.03)

Bank To Customer Account Report (camt.052.001.02)

Bank To Customer Statement (camt.053.001.02)

Bank To Customer Debit Credit Notification (camt.054.001.02)

Figure 25.11 depicts these message flows.

FIGURE 25.11 CGI Message Flows

These CGI templates detail specific implementation guidance (or market practice) on the use of the respective ISO 20022 XML schema, element by element. Each element is designated a usage status, for example, “R”—Required, “C”—Conditional, “BD”—Bilaterally Determined, “NU”—Not Used. For the credit transfer, this detailed guidance is further segmented by:

Automated clearinghouse—domestic and international. General usage is equivalent to low-value or nonurgent transactions. It typically is associated with a batch process and/or low-priority transactions.

Wires—domestic and international. General usage is equivalent to high-value or urgent transactions with high priority.

Cheques/drafts. Typically, paper-based transactions.

Users of these templates can benefit from a common and unambiguous approach to market practice that is designed to work across multiple financial institutions. In practice, this means that bank customers can take their payments initiation processing to a more consistent level based on a single global common implementation template for each of their outbound payments initiation message types (credit transfer and direct debit) and for their various inbound account and status reporting message types. From a competition and risk management perspective, it should simplify the process for a corporate to expand or switch to a new bank.

The CGI templates incorporate a concept of ‘data overpopulation’ that allows corporates to effectively provide not only the same information, but also all of their information to each of their target financial institutions. This information is then filtered by each receiving institution based on the requested payment method, clearing channel, and any institution-specific requirements. The use of a single common template in this manner will reduce cost and complexity.

Another dimension to the CGI implementation templates is the use of appendices to provide further elaboration and specific guidance. For example, a list of individual payment system service level codes, country/region specific requirements, and implementation use cases. Appendices support a more frequent maintenance cycle and are created, based on the business requirements of a specific message. These appendices recognise that certain markets may be subject to slightly different regulations, and each may have its own local market practices that change over time with the emergence of new regulations and business requirements. For example, where a bank branch identification is required, or where local language is required, or where country specific regulatory and/or tax reporting is required.

Significantly, the CGI implementation templates are also serving as a blueprint for enterprise resource planning (ERP) and Treasury management system (TMS) vendors to incorporate these as part of their solution offerings. SAP made product announcements to this end in December 2011.

MyStandards

An ongoing development by SWIFT is MyStandards. It encompasses standards definitions, usage guidelines, bilateral agreements, and analysis tools. MyStandards is positioned as a collaborative web-based tool to efficiently manage new releases and better understand market practice. MyStandards is currently moving from pilot to production, with the first official release expected in May 2012.

It is anticipated that the implementation templates from CGI have been incorporated in MyStandards and will be an important reference point for the formulation and analysis of this and related market practice.

Conclusions

The potential for CGI to streamline the broad community adoption of ISO 20022 for payments is large and illustrates that effective collaboration in defining market practice can be a win-win situation for all players involved, notably the financial institutions and their corporate customers. Achieving true multi-bank integration depends on a common template for information exchange that not only caters to the core data elements but also extends to providing support for those banks that may wish to offer value added solutions that are over and above the core CGI message implementation template. Here the concept of ‘data overpopulation’ plays a key role, and should not be overlooked in implementation.

A challenge for CGI will be how it provides implementation guidance for the migration from one version of the base ISO 20022 standard to the next. Later in 2012, version 4 of the pain.001.001 will be published, the current template is based on version 3.

Finally, promotion of CGI needs strengthening. Consistent with ISO 20022, the open and free availability of the CGI collateral should be a given, but a dedicated and more visible home for CGI is something that should be brought to the fore.

Contributed by David Dobbing, business manager banking and payments standards, SWIFT

---

SUMMARY

Good system selection, implementation, and maintenance are far more than mere concepts. Many hurdles can crop up that can impede any of these stages, but with adequate and simple but intelligent thought and execution, Treasury systems can emerge as true winners in adding to a company’s profitability.