Corporate actions processing still remains one of the back-office areas which are less automated.

This is a paradox for a process that is complex, highly paper-based and where the risk exposure associated with a bad corporate action can be significant.

Too often, corporate actions have been viewed as a huge challenge offering less strategic benefits than processing - for example - new instruments.

The difficulty in building a compelling business case is one of the main reasons that can explain the reluctance of financial institutions to go through a project of automation.

As for any IT application, but maybe even more important in this area, the initiation of the project must be carefully planned and justified with:

 A clear business case defining the objective
 A specific definition of the scope and limits of the project to manage the operational risks
 A pragmatic scenario for the implementation project

It might seem obvious, although several large projects recently failed due to this lack of clarity up-front.

Experience with very different scenarios and types of clients have shown that, the following basic guidelines can be considered as key for success:

 Agree with your management about the objectives: cost reduction, risk control, client service quality.

As an example:
 
o Reducing the operational risk and cost:

By automating tasks and by reducing the number of manual interventions, you can reduce operational risks. A single “missed” corporate action can result in a loss of confidence and eventually in liabilities of several millions.

Dividing error costs by 3 or 4 is a goal that can be achieved easily.

o Volume pressure and resource management:

Income and corporate actions processing is manually intensive. By increasing the STP rate, you can be less subject to seasonal peaks and reduce pressure on resources during these periods. In addition, staff can be assigned to more value-added tasks.

Decreasing unit costs by 30% or 40% is a realistic objective.

o Customer service quality:

Clients are becoming more and more demanding in terms of notifications, deadlines, mail supports etc. All services are difficult to provide without automation. In addition, value-added services, such as tax reclaim or proxy voting can be offered to clients.

It is then necessary to set up a list of qualitative service improvements with a few simple quality service ratios to be reached.

o Optimization of capital costs implied by Basel II requirements on operational risks is also quantifiable.

 Do not consider SWIFT ISO 15022 standard as just an interfacing project, but use it as an opportunity to a total process re-engineering of your back-office, turning its organisation to full STP mode with an efficient exceptions handling structure.

It is therefore essential to allocate your most experienced business staff to the project, as it is a complex area difficult to be fully understood by the IT developers.

 About the new standards, several “early birds” on the market, compliant with the SWIFT ISO 15022 standards, are complaining that their counterparties (client and market sides)are not compliant, thus destroying their efforts.

It’s exactly the same situation as several years ago, when the SWIFT 5xx messages were introduced: the STP rates were low only because a very few basic fields were simply wrong: BIC codes, ISIN codes, etc. Experience proved that it is only by a progressive but persistent effort that you see the results after some time.

After the initial “ROI justification” directed to your management, your main decision is to decide if you ask your internal IT team to develop this generic application or if you wish to investigate the “software vendor package” approach.

A classical SWOT analysis (Strength, Weakness, Opportunity, and Threat) is particularly suitable to assess each option:

 Cost
 Time to market
 Support and maintenance
 Differentiating factor from your competitors
 Operational risk of the IT project
 
Once this initial due diligence is achieved, it may become quite evident that the external package solution emerges as a relevant response to quickly modernize and in a cost-effective manner, a back office task where there is no special competitive differentiation in terms of core processes.

Practical cases

When a financial institution, wishing to improve its CA back office operations has decided to use a vendor package, the next two key questions are:

1. Should we choose ONE product to cover the entire range of functionalities needed by the corporate actions process or not?
2. How should we implement the solution?

The range of functions needed to cover the full corporate actions process is quite large:

 Securities database management: data cleansing, golden record generation, reconciliation of data    between data providers, CSD’s, local sub-custodians, global custodians
 Event management, client (pre) non notifications, official or not
 Client instruction management, In/Out, mandatory/optional/by default/predefined
 Agents/markets consolidation & communication
 Event proceeds calculation, reconciliation agents/markets and clients side
 Withholding tax calculation & tax reclaim process
 Accounting

To further complicate matters, each of these functions needs to interface with a series of external information system such as:

 Securities master file
 Clients & accounts structure
 Generic market data
 Accounting
 Portfolios & position keeping system
 Trades & instructions with their status
 Potentially, external risk, credit, cash, CRM external global systems

If the scope of the project defined initially is the full range of functions supporting the whole CA process, the option based on the “best of breed” approach (i.e.: several different packages to cover all the functions) can clearly lead to an IT nightmare as it would mean building lots of different interfaces and synchronising the various databases.

The right solution should be the choice of one single package able to cover simply and easily the range of functionality needed.

For example, if an efficient central database system has already been installed for the needs of several business areas of the group, there is no need to duplicate the securities database system, as the CA package will interface with it.

Another example is the connectivity to SWIFT cash and securities facilities. If the organization has installed such a generic platform, there is no need to duplicate these functionalities; the CA package will simply send/receive the adequate 5xx messages to /from it.

Each block has to be taken or not according to the existing structure and to the scope of the project.

Over the last few years, a couple of corporate actions packages offering end-to-end processing with a modular approach have emerged in the market.

In the “Implementation Phase”, the key lessons learnt from experience with clients are:  “Find the less risky scenarios, avoiding any big-bang”

Particularly if the project objective is also to re-engineer the back office structure, a progressive approach is safer.

Fortunately, this is an area where many different scenarios may be designed.

The criteria for choice are simple:

 Urgent topics or “quick wins” first
 Weak functions with largest savings
 Client quality improvement
 Area with large risk control problems

The lines along which one can build progressive scenarios are multiple:

 By type of instruments: fixed income, equities, treasuries, etc: very frequently, large organisations may have different legacy systems, specific to specific instruments such as mortgage backed, or warrants, etc. This approach allows one to stop old applications one by one and build new interfaces one by one to obtain at the end the full convergence to only one CA system.

 By country; in large, international networks this allows simultaneously a progressive restructuring of the back office staff and a progressive development of the specific interfaces in each country with the local CSD’s, CCH’s, NCB’s and data providers.
 
 By CA type; mandatory, optional with choice, information only, proxy etc. This approach allows a progressive growth of the volumes and the workload, as well as the introduction step by step of new functions.

 By type of clients; retail, institutional, trading rooms, private banking, Asset Management front offices, fund accounting, etc. This also allows a progressive introduction of  increased volumes and functions.

 By CA functions in the range of those needed, as said before, from data cleansing, client    notifications, etc through to accounting, again to allow the progressive development of workload and interface activation.

Conclusion

The decision to use an external package to support CA operations and automation is certainly the right and most efficient choice in an area of the financial operations where the IT applications are expensive, risky and difficult to maintain.

The key for success is to think up-front of a very pragmatic and practical implementation plan avoiding any industrially risky big bang.