About Me

My photo
I am deputy editor at The Banker, a Financial Times publication. I joined the magazine in August 2015 as transaction banking and technology editor, which remain the beats I cover. Previously I was features editor at Profit & Loss, an FX and derivatives publication and events company. Before that I was editorial director of Treasury Today following a period as editor of gtnews.com. I also worked on Banking Technology, Computer Weekly, and IBM Computer Today. I have a BSc from the University of Victoria, Canada.

Saturday, 14 August 2010

SWIFT Service Bureau Q&A with Ben Schol, Unilever

13 July 2010

In this Q&A, Ben Schol, project manager at Unilever, explains why the company decided to switch to SWIFT connectivity.

Unilever uses Fundtech's ServiceBureau for SWIFTNet connectivity. It migrated its inhouse solution in the shared service centre (SSC) to Fundtech's ServiceBureau in October 2009 in less than three months.

Q (gtnews): What made you decide to switch to SWIFT connectivity?

A (Ben Schol, Unilever): Each bank provides its own platform for connectivity, with its own protocol and file formats. This adds complexity when interfacing your back-end systems with these platforms. SWIFT removes a lot of this complexity. In addition, adding another bank becomes a breeze.

Q (gtnews): What method did you use to connect: Standardised Corporate Environment (SCORE), Member Administered Closed User Group (MA-CUG) or Alliance Lite?

A (Schol): At the moment we decided to use SWIFT, the only available method for connecting was through a MA-CUG. We had a look at SCORE when it came available, but didn’t see any advantage in switching. If we were starting now, we would definitely go for SCORE because the administration is much easier.

Q (gtnews): Why did you outsource the connectivity to a service bureau?

A (Schol): Maintaining and supporting a SWIFT environment requires highly trained and skilled personnel. After running the environment in-house for two years it became clear we were not able to build up these skills and thus started to look for alternatives, i.e. outsourcing maintenance and support or outsourcing the entire environment. Given the internal policies around remote access for maintenance and support, outsourcing the entire environment seemed to be the best solution.

Q (gtnews): Were there specific hurdles that had to be overcome?

A (Schol): First of all, of course, you will have to specify your requirements - both from a technical and business perspective. Next you will have to find a partner who best fits these requirements and your company culture.

Q (gtnews): Are there plans in the pipeline to expand your use of SWIFT?

A (Schol): Unilever currently uses the FIN, FileAct and Accord services. There currently are no plans to expand this.

First published on www.gtnews.com 

Financial Professionals Lack Confidence in Risk and Performance Metrics

6 August 2010

A recent survey found that the vast majority (85%) of financial services and IT professionals do not have performance management systems completely integrated with risk analysis systems, according to Oracle's 'European Confidence Report'. In addition, 41% of those that do not currently assess risk and performance together are not seeking to actively incorporate risk into decision-making. This means that decision-makers will continue to make critical business choices without accounting for the all challenges that their business face.

In an interview with gtnews, Nazif Mohammed, vice president Europe, Middle East and Africa (EMEA), finances services, Oracle said: "We are living through incredible times - [the crisis] is probably the most expensive training exercise in bank performance measurement. Even the layperson on the street is now aware of stress testing. The aim of the survey was to understand the 'new normal' and see if the banks are actively incorporating risk into their day-to-day decision-making."

The research, conducted by Vanson Bourne, surveyed 228 financial services professionals and 222 IT professionals in financial institutions across Europe, including the UK and Ireland, France, Germany, Italy, Belgium, the Netherlands, Luxembourg and Switzerland.

The survey's key findings include:

•Almost half of all participating banks were not confident of the accuracy of their risk and counterparty related data. Alarmingly, more than one in seven (14%) admitted they are unable to monitor and respond to changing risk scenarios.

•Financial institutions are not leveraging integrated risk information in decision-making: 41% of financial institutions surveyed do not currently assess risk and performance together, and only 18% of respondents reported an ability to deliver performance and risk information to the business in real-time.

•Existing IT systems are unable to deliver what the business needs to react immediately to external events: only 26% of respondents are confident that their existing IT system is capable of using stored data to provide a full risk analysis across all business units.

•Almost two-thirds (64%) do not have confidence that IT is able to provide a 360-degree view of the entire business. For example, only 32% of the participating banks claimed they had access to vital data like counterparty information and 25% of the participating UK banks couldn't even produce this information.

Mohammed said: "Financial institutions understand how important it is to assess risk and performance management together, but have great difficulty in doing so for various reasons, such as data silos or legacy banking systems. The problem is also in the way businesses are structured, with a finance team that looks at profitability and a risk management team that solely looks at risk, and those shall not come together. Many times at our customer meetings these professionals exchange cards because they are meeting for the first time."

Across EMEA, only 24% see risk assessment and performance management as being tightly dependent, where both aspects are continuously assessed and reported on. Despite this, almost a third (29%) of respondents have an element of their remuneration package based on the accuracy of their information and in next three to five years, 58% will see risk actively be built into the process of pricing products. With these considerations it is surprising that more banks are not actively incorporating risk into business performance already.

Meeting the Compliance Challenge

The current business climate also means that financial institutions will continue to be subject to more regulations, making the need for integrated systems even more critical. Eighty six percent expect to see some or high levels of changes in the regulatory load on their organisation or in the financial services market. Compounding this problem is the fact that 40% believe that increasing compliance coupled with tougher deadlines will continue to hinder data accuracy.

"Financial institutions take regulatory pressures very seriously, but the challenge is in the approach," said Mohammed. "Do they add yet another system and continue trying to patch the holes to meet the requirements? This is a common approach - put a reporting system in place for liquidity management, another for pulling data for stress testing, etc. But this is done with very little co-ordination across the group. Financial institutions need to take a different approach where these systems are seen are part of an overall architecture of addressing the data, the transaction and the reporting capabilities."

First published on www.gtnews.com 

Choosing a SWIFT service bureau

Before SWIFT service bureaus came along, the only way that a corporate could connect was by going direct. There are still reasons why a corporate would choose to host SWIFTNet connectivity in-house, such as the desire for full control or to avoid the risk of an intermediary between themselves and their bank.

But even for corporates with sizable IT departments, maintaining SWIFT-specific expertise in-house would entail training up their own IT personnel and security officers, as well as sending them on SWIFT courses just to maintain the system, which are all costly and time consuming.

“When we set up our service bureau, we certainly thought that it was going to be for the smaller end of the market - those companies that couldn’t justify the expense of the direct route. But what we quickly learned that it was more down to company culture,” says John Ballantyne, UK sales manager at SMA Financial. “Very large corporates have made the decision to outsource the infrastructure simply because they didn’t want the hassle and expense of running it inhouse.”

He says that less than 5% of the corporate implementations that SMA Financial has done over the past two to three years have been direct implementations. SWIFT service bureaus fulfil an important role by offering SWIFT connectivity without major and recurring investment in technology, infrastructure and specialist personnel.

Differentiating Between Service Bureaus

Not all service bureaus are alike: some solely provide the connectivity while others offer a fully-managed outsourced solution, which includes hosting the infrastructure and supporting technical operations. This reduces the cost because corporates are linking into a shared environment across multiple clients.

In addition, many service bureaus are developing value-add services, such as cash reporting, funds transfer, electronic bank account management (eBAM), reconciliation, payment exceptions and investigations (E&I), anti-money laundering (AML) filtering, etc.

When selecting a service bureau, the most important part is to ensure that the link is not weaker than SWIFT itself - does the service bureau meet the same parameters as SWIFT in terms of availability, security, resilience, nonrepudiation, and guaranteed message deliveries?

Ballantyne says that the first port of call is SWIFT certification. SWIFT lists in which areas the service bureaus are accredited, as well as the certification level of the consultant teams, etc.

Elie Lasker, head of corporate market, SWIFT, says that a service bureau should exhibit corporate-specific experience and expertise. “What we see now is that many service bureaus have gained more experience with corporates - and clearly some service bureaus are more specialised in the corporate market. One of the typical questions that a corporate should ask is how many corporates does the service bureau already work with?” In addition, ensuring that the service bureau has a disaster recovery site is critical to maintaining the 99.995% reliability and resiliency that SWIFT pledges.

“Corporates should also ask about the service they provide in terms of onboarding banks. The process involves both technical and administrative aspects for which a corporate doesn’t always have the bandwidth. Therefore, it is usually better that a third party provides this kind of assistance. It will simply make onboarding faster,” says Lasker.

Franklin Van Weezendonk, senior vice president, Axletree Solutions, adds that a corporate should check if the service bureau uses SWIFT products. “For example, SWIFT has a product called SWIFT Alliance Integrator, which a service bureau will pay a fee to use. Some service bureaus have developed an integration solution in-house - a proprietary product - which makes it cheaper.

“But when SWIFT makes a major or minor upgrade - let alone a whole new SWIFT release - are those proprietary products going to meet the new requirements? Whereas if a service bureau uses SWIFT-approved products, then you don’t run that risk,” he says.

Lastly, service bureaus distinguish themselves through value-added options, in terms of data enrichment, transformation, reporting, or light treasury applications to overlap with existing systems in the treasury back office to provide an overall solution.

Ballantyne believes that although corporate treasurers like to hear about sophisticated additional options that a service bureau can provide, fundamentally they select their bureau based on the core function of simply connecting them to SWIFT.

“Most treasurers already have this value-add within their trading applications and internal treasury products, and so I think it is a bit of a red herring, actually,” he says. “What the corporate treasurer really wants is to feel very confident that a service bureau can provide the core services."

Factors to consider when selecting a SWIFT bureau service
1. Accredited resources.
2. Depth and breadth of experience.
3. Scale up or down.
4. Long-term client care.
5. Proven track record.
6. Value-added services.
7. Disaster recovery.
8. Independent partner.
9. Location.
10. Financial stability.
Source: SMA Financial

First published on www.gtnews.com 

Moving to SWIFTNet

One of the most difficult hurdles corporate treasuries must overcome when planning a move to SWIFTNet is developing a solid business case, particularly in the current environment when infrastructure budgets are tight

When creating a business case, a SWIFT project should be part of an overall drive towards treasury centralisation. According to Elie Lasker, head of corporate market, SWIFT, the hardest part of the project is what comes before, for example centralising enterprise resource planning (ERP) systems or treasury management systems (TMS), or re-engineering treasury processes.

The ‘icing on the cake’ is then to be able to connect efficiently and easily to the different banks via SWIFT. “A treasurer doesn’t wake up one day and say ‘I want to connect to SWIFT’. There is no significant benefit for a corporate if there isn’t a project aimed at streamlining behind it,” says Lasker.

But once a centralisation project is in the pipeline, where does a treasurer start
when putting together a business case for SWIFT connectivity that stands up to budget pressures?

Developing the SWIFTNet Business Case

A business case should answer the following questions:

1. Which SWIFTNet schemes are available? Which is the most suitable for your business?

2. Will SWIFTNet meet the objectives of increased reliability, control and cash visibility?

3. What are the costs and benefits of the SWIFTNet schemes?

4. How do the SWIFTNet schemes (plus required middleware) fit in the contemplated treasury technology ecosystem, particularly in terms of integration?

5. What are the main risk factors of any SWIFTNet scheme?

6. What does a SWIFTNet scheme implementation plan contain: steps, duration and legal documents?

Let’s explore each question in more detail.

1. Connectivity options: SWIFTNet schemes

- Private infrastructure: a SWIFTNet connectivity infrastructure which is established, owned, operated and managed by a company’s own technical team.

- Shared infrastructure: a SWIFTNet connectivity infrastructure which is established by outsourcing to a third party vendor, commonly called a service bureau, who owns, operates and manages it on behalf of the company.

- Alliance Lite: a simplified, internet-based secure connectivity to SWIFTNet. It is a low-cost, low-volume solution but may not be optimum for central treasury but might be useful if a company wishes to give direct access to SWIFT to its smaller subsidiaries.

It is more usual for corporates to go down the shared infrastructure route, which has a number of advantages including:

- Technical interfacing issues are handled by the service bureau.

- Removes the complexity of managing SWIFTNet environment in-house, while saving costs on IT and SWIFT specific personnel.

- Future-proof access to SWIFTNet services.

Some companies will see disadvantages as well, including the fact that an additional external party adds an element of risk, particularly around the area of storing sensitive data. Reassurance from the service bureau around the handling of this data will be required.

2. Reliability, control and increased cash visibility

Many companies express concerns about the reliability of current electronic banking (ebanking) systems and the possibility of disruption in delivery of information. The SWIFTNet schemes are reliable and form a negligible risk: SWIFT publicly states its availability goal is 99.995%. In addition, SWIFT offers a guaranteed delivery mechanism for payments for messages once the sender has received an acknowledgement (known as an ACK) from SWIFT. They are also financially liable for non-delivered messages.

When using a service bureau, a company will be dependent on the middleware of the service bureau, which might also be seen as adding an element of risk. One of the major benefits of SWIFTNet is that central treasury can gain better control through having all banks report through SWIFTNet, thereby gaining global visibility of bank statements and information. In addition, payment authorisation can be left at a local level, with the possibility of adding a regional signature as required.

SWIFT enables corporate treasurers to achieve greater cash visibility by:

- Enabling them to collect balance and transaction data daily (and intraday) in a standardised form from a corporate’s various banks around the world.

- There is no need to log-on to separate e-banking portals.

- Central treasury receives this information directly from the banks in the regions rather than relying on the subsidiaries to report.

- Standardised data formats means cash balances can more easily be integrated into a TMS or ERP system to create a consolidated view.

- Adding or deleting banks from the list is made easier due to the bankindependent nature of SWIFTNet.

3. Cost/benefit analysis

Many companies are using SWIFTNet as part of a programme to centralise their treasury operations into one location. The main cost benefits will come from a reduction in staff numbers. They also want to improve reliability, gain greater cash visibility and introduce greater control within the treasury structure, which is more difficult to quantify.

4. System fit

For many companies, their TMS will become the gateway into SWIFT. Most or all data and associated security profiles will be stored in the TMS. The main issue is to ensure that there is an interface between both the TMS and SWIFT with flows both outbound for payments and inbound for balance and transactions statements.

Another issue that will need to be decided relates to payment processing. A company may wish to leave local payment processing in the local countries. However, central treasury may want to retain some control over the authorisation of local payments. There are many ways this can be achieved.

One way involves making the TMS the central conduit for all flows but this will require a link between the TMS and the local subsidiaries. This could be achieved by giving the subsidiaries limited access to the TMS payment input module.

Another approach would be to provide the local subsidiaries with SWIFTNet access through a product called Alliance Access. This is a view into SWIFT and allows users to input, verify and authorise payment instructions. These different processes can be physically performed in any location. This means, for example, that a subsidiary could input and verify a payment instruction and then central treasury could authorise it. One of the problems with this approach is that it is outside the TMS and so issues such as bank reconciliation need to be addressed differently.

5. Risks

When a company stops using its bank’s ebanking system, this may impact its relationship with that bank. It is advisable for companies considering a SWIFTNet approach to involve their main cash management banks in the process.

Although the method of receiving information the bank will change, the actual number of transactions being processed by the bank will not. Therefore, the risk is negligible. Many banks already have clients using SWIFTNet and are used to this approach.

6. A SWIFTNet implementation plan

There are then five main stages in planning and implementation:

1. Define the scope

- What services are needed - payments,balance and transaction reporting?

- What banks will be involved and are they SWIFTNet-compliant?

- What type of connectivity is required? Formats and messaging - FIN, FileAct, etc (see Message file formats box).

2. Contact the banks

- The company will need to let the banks know that it intends to use SWIFTNet. New bilateral agreements may need to be put in place with the banks involved.

- Agree service conditions.

- Get copies of legal template if available.

3. Software and connectivity

- Contact SWIFT and/or service bureau.

- Define schemes required.

4. Pilot period

- Join SWIFT.

- Install software and connect to SWIFT.

- Run test pilot.

5. Roll out - per bank

- Kick-off meeting.

- Setup and test live environment.

- Go live.

- Revisit and ensure that objectives have been met.

SWIFT estimates that a project of this size should take between three and six months to complete if a service bureau is used and six to nine months if a direct connection approach is chosen (see Implementing SWIFT box).

Box 1 Message file formats

FIN (individual messages)
● Typically used for single transactions, e.g. high-value payments, deal confirmations and reporting.
● Store and forward delivery of highly structured messages in strict SWIFT FIN (MT) format.
● Messages are validated by SWIFT on transmission.

FileAct (file transfer)
● Typically used for bulk payments (e.g. salaries, commercial payments, direct debits, etc) and reporting.
● Secure file transfer over SWIFTNet.
● Delivered in real time or store and forward mode.
● Files can be in any format - payments files, iDOC, ISO 20022 XML, domestic ACH formats, BAI, etc.
● Not validated by SWIFT.

Box 2 MA-CUG versus SCORE

A ‘very large’ UK corporate currently has more than 300 bank accounts with more than 20 banks. It currently uses in excess of 15 local electronic banking systems. Treasury has approximately 200 payments per day. This results in approximately 4000 payments per month. The number of payments done by the local entities is approximately double that per month.

Presently, payments are sent to the banks by the local entity. The company is currently centralising its payments into a payments factory. With such a large number of banks SWIFTNet is an ideal consideration. The company plans to use its TMS and ERP system in conjunction with SWIFTNet to create and transmit the payment files to its banks and then collect the bank information.

When comparing MA-CUG and SCORE, SCORE is seen as the preferred route for a company who is looking to perform payments and reporting through SWIFT. Given the multiple banks involved, the MA-CUG route would necessitate the establishment of connections with each of these banks separately. This in itself would be a time-consuming and onerous task. The SCORE approach on the other hand provides a single channel to multiple banks allowing the company to operate accounts payable (A/P), accounts receivable (A/R) and treasury-related activities (if required) through the SWIFT network. In this case the corporate used SCORE and a local SWIFT service bureau to connect because it did not feel it had sufficient in-house expertise to build the connection.

First published on www.gtnews.com