The most recent Corporates on SWIFT newsletter (Issue 2
Q3 2009)
published by SWIFT, contained some interesting updates.  To many who are very familiar with SWIFT and
SCORE, some of these items are not real news, but they should be commented on.

 

  1. Changes
    to SCORE requirements:

 “Any
corporate can now join SWIFT, provided it is recommended by a bank located in a
FATF country willing to exchange messages with it.”

 We believe
this is a very positive step for SWIFT SCORE. 
Previously the corporate had to be listed on an exchange in a FATF
country, and this excluded many private corporations and non-bank financial
institutions.  This has now been opened
up. 

 

  1. ISO
    20022 account reporting is out of pilot and available.

Again, a
very positive step as corporates are demanding bank data that are both easily
incorporated into their other treasury and accounting systems and rich in
content.  The XML standard offers
both.  The pilot banks, as reported by
SWIFT, were: ABN AMRO/Royal Bank of Scotland, Bank of America,
BNP-Paribas, Citi, Commerzbank, Deutsche Bank, HSBC, J.P. Morgan, and Societe
Generale.

 For those
who like jargon…the MT 940/942 standards are being replaced by a series of MX
standards.  MT are the FIN type messages
and MX are the XML messages.  The
implementation guide was released on 22 June and is available on the swiftcommunity.net website.

 

  1. Three Articles
    referencing SWIFT
    Alliance Lite:

 There are
essentially three ways you can communicate with the SWIFT network.  One
is a direct connection where you buy or build a connection onto the
network.  The next method is using a Service Bureau, an outsourced connection,
where you connect to the Service Bureau via the internet, and the Service
Bureau connects to SWIFT.  The third method is via Alliance
Lite.  Alliance Lite is somewhat of a mash
up of the two previous methods with which you are able to connect directly to
SWIFT with very little hardware and software via the internet.   All of these methods have considerable
advantages and disadvantages that need to be weighed by the customer.  Caveat Emptor.

 What we really found interesting were
articles that referenced the Alliance Lite product.  They were interesting not because of Alliance
Lite itself, but because the articles seemed to confirm assumptions that
implementation of Alliance Lite is quick and that there are still significant
limitations in what messages a corporate can exchange when using Alliance Lite.  At least two things will remain unknown for
some time: “How will the product age?” and, “What upkeep and maintenance will
be required by the corporate customer as the product ages?”

 

  1. Migration
    from ETEBAC.

 At SIBOS 2008, SWIFT announced that at least
80,000 French Corporates were going to be confronted with changing from the
French national ETEBAC (corporate to bank reporting) standard to the SWIFT
Standard (ISO20022).  According to Andre
Casterman, director of SWIFT France, that number is now greater than 90,000. This
should push many corporates onto SWIFT and, as the article on BRED Banque
Populaire suggests, the quickest, or the most innovative, banks to support this
migration will be the winners in this space.

see www.strategictreasurer.com or www.swiftcorporateworkshop.com for more information.

-r

 

The 2nd SWIFT Corporate Workshop will be held in New York on March 10th.  The event is hosted by Strategic Treasurer and Camino Consulting and the bank sponsor is J.P. Morgan. 

Go to www.swiftcorporateworkshop.com to view information and to register. If you register, please enter BLOG in the "How did you hear about us?" section.

 

While it is often only recognized in times of crisis or great turmoil, the need for good information at the right time of great valueGood information too late is…actually rather useless.

If you have financial accounts, you have a reason for them (if not, it is time to shut them down). Each account represents a point of exposure. Exposure to inefficiency is not good.  Exposure to fraud or exposure to substantial loss ranges from bad to very bad.  Since your remaining accounts are needed, you need to have access to current and useful information as a matter of strategy not as a matter of convenience. Having access to current information is a need (this will vary based on the type of account it is and the type of transactions you are executing in these accounts). 

If you are performing a cost-benefit analysis on the information cost on an account by account basis, that could signal that something is wrong. If you need the account, you need to have good information on that account for various reasons.  For accounting.  For efficiency of various processes.  For visibility purposes. Once you start limiting your view you lose visibility…and efficiency.  This is a problem on several fronts.

Fighting to justify the cost of securing data from each individual account is a no-win process.  The justification needs to be done on the mass of accounts.  And, while some accounts are far more critical than others, the interconnectedness of your 'cash' will normally necessitate seeing entire picture.  Thinking that you are seeing the majority of the picture is often a mirage or myth.  You think you are seeing 95% of your portfolio or cash.  In reality you are going to miss the piece that will come back to bite you.  And, bites can hurt. In theory and during 'normal' times a limited view seems safe.  Reality is not artificially bound to act like theory.

If you need visibility and that supports your strategy and helps you fulfill your group's mission, the burden of proof for even suggesting a cost benefit analysis falls on the one who wants to exclude this account or that from your view.

I want to see the cost-benefit analysis of doing a cost-benefit analysis on a strategic activity!

(There are certainly some reasons for not accessing daily information on some accounts.  However, this is rare. Typically, if an account doesn't need to be viewed regularly, it can either be tightly restricted or eliminated.).

See us in Chicago or at www.swiftcorporateworkshop.com on November 6th, 2008.

-c

 

Visibility, Treasury Technology and SWIFT

SWIFT Corporate Access.  What in the world is that?  Isn't SWIFT something for the banks to pass on secure messages between each other?

The buzz around corporate access is really quite simple from the Treasurer's perspective.

  • Visibility is important to liquidity management and risk management.  Visibility means being able to see where you funds are coming from and where they are going…today and in the future.  This requires access into several different types of data and information.
  • Efficiency  Clean and efficient processes reduce risk and remain important to nearly every organization.  Efficiency refers to doing things right and avoiding problems.  A typical prescription for efficiency is straight through processing or STP.  SWIFT provides an avenue into a number of key processes – and now you can connect into more processes.  (We'll look at this in a later blog).
    • Regarding Visibility and SWIFT, let's look a bit more closely:
      • Balance Information.  Where is your money? If you have accounts all over the globe at various banks, you need to access that information.  This can be a pain with all of the connections that must be setup, managed and monitored.  What should treasury be doing anyway?  SWIFT can allow you to use their information network to get all or a majority of that information simply, securely and with some measure of difficulty.  There are certainly ways to make that quite a bit easier and we'll cover that later.
      • Investment, Debt and Hedge Information.  Your custodian or your loan information will typically represent a fair amount of your cash flow.  Access to that data can come from the custodian or from your own records. SWIFT may be a channel for some of this data as well.
      • Internal Information.  CAPEX spending, large tax payments, etc. – all probably originate from within the organization.  Forecasting information from operating flows – this too comes from within.

Being able to connect to a single source, that is highly secure and is the top priority connection for your banks means life can get a little easier.  The focus can move off of operational activities and onto analysis. 

On a related topic, we are co-hosting the November 6th event called SWIFT Corporate Workshop with Camino Consulting.  There is a dedicated website for this event at www.swiftcorporateworkshop.com.  We encourage you to visit the site and consider attending. 
Thumbnail

There are too many misperceptions out there about SWIFT and about Corporate Access.  You owe it to your organization to develop a working knowledge of this important topic.

-c

 

This is a true story.  Names have been changed to protect the guilty:

Recently while working for a client that had a major bank’s data being reported to their Treasury Work Station via an FTP link there was a problem.  The data was not reported on time by the bank.  This data is crucial to the corporate for making some key financial decisions.  So, of course I called the bank help desk and talked to “Tim” (not his real name).

ME:  Hello Tim my customer number is #123456 and my product number is # abc123 and we did not get our FTP file with our bank data on it today.
Tim:  Right, I have had a couple of calls regarding that product and I talked to the guy responsible for that application (the one that gathers the transaction data, matches it to your bank accounts and packages it for your daily account download).  Well, the primary guy is out, I called his pager, he just got back to me and he doesn’t know when it will be fixed.
ME:  Ok, so our client needs that information to make some pretty important cash/banking decisions and you don’t know when it will be fixed.
Tim:  Right, call me back in about a half hour and I will give you an update.
30 Min Later:
Me:  Tim my customer number is #123456 and my product number is # abc123 and we did not get our FTP file with our bank data on it today…I called earlier
Tim:  The guy who works on that application has it running and it will probably take about 15 minutes for the job to get to your account. (A small technical discussion on what I should use for timing the FTP pull ensued).
Me:  Thanks Tim

Bottom line:

  • The bank knew there was a problem, they had been called by other customers,  and notified no one…(Perhaps if we don’t tell them they won’t know).
  • Then when there was an ETA on the fix….no one called,
  • Finally when the fix was done….yep, still no call.
  • The customer service group expects their corporate customers to keep calling them back to get status on a problem.
  • It might be a bit of a stretch to expect a call, but if the client did not NEED this information in a timely manner they would not PAY for this service.   It is not nice-to-have information.
  • Note to Tim:  There is a old database/email trick called distribution lists.
  • Most people don’t realize how many points of failure there are in getting this data put through, and that is fine.  However, when there is a known problem (if you have a distribution list with the names of the clients on a particular service – which many bank operation areas do), you can send them an email telling them that there was a failure and what you are doing about it…it’s called customer service.

-r

 

 

Accessing banking information is extremely important for a
corporation. There are a number of
options available to corporations who desire access. These include:

  •  Basic bank web site
  •  ASP treasury work station
  •  Higher-end installed treasury work station
  •     Data aggregators or consolidators that package
    multiple banks worth of data into one feed (for a workstation, ERP or other
    similar use).
  •  SWIFT SCORE[i],
    or MA-CUG[ii]

The key question that will determine your satisfaction with any
of the above technology solutions to your corporate data problem is:  “What exactly do you want the product or
service to do?”

There is a fable about a young king who called all of his
advisors into his chambers and gave them what he deemed as the simplest of
tasks. “Bring me a stone.” As you can
imagine, there are many versions of what kind of stone the king could
want. His affluent and aged advisors returned
with precious jewels, while his engineering advisors brought strong stones that
could support the great weight of a building. Meanwhile his interior decorator advisors offered polished granite that was
aesthetically
pleasing for the counter tops. When all
these returned and stood before him, the king was yet unhappy with their
selections, for “a stone” has many meanings and none knew the meaning that lay
within the mind of the king. It is
obvious that without a clear description of what you want you will likely be
dissatisfied.

The problem of poorly clarified expectations exists in the
Corporate-to-Bank information space as well. Many customers are not satisfied with their solutions simply because
they have asked for a stone, and were overwhelmed by the number of stones
available. They are wowed by a technology
demonstration that shows many jewels, or they are impressed by the ability to
access great data. Perhaps they like the
polish and look of the product, but they really don’t know what kind of stone
they want.

To make matters much worse  overzealous sales persons potentially promise
that this ‘stone’ can change shapes and be just like that other ‘stone’ and
handle the same breadth or types of data, or that with just a little training  the client can make this stone more
polished. So, now the buyer is even more
confused about which stone is appropriate.

Then someone from the implementation team arrives and tells the
client that in fact this stone is not really a stone; it is a rock, and in
order to make it into the right stone it will take more hours to polish this
rock than the sales staff allocated. Or
better said, what was promised is not in fact possible or takes much more
effort than was advertised. This is
really a recipe for geological client dissatisfaction.

Finally, during the implementation of the now identified
rock another department from the company hears about bank data availability
through Treasury and they want a piece of the rock. (No implied insurance endorsements). The implementation team wants to provide
enterprise value and show off the new rock to the rest of the company so they
over promise, and give the other department what they want, even if it was
initially out of scope, and again, more time polishing the rocks is needed.

How can a business avoid asking for a stone?

  1. Develop
         a broad and thoughtful needs-analysis or critical needs document. Who in the business needs what
         information from the Bank, and how are they getting it now?
  2. Survey
         the market to determine what technology is available and used by companies
         that have similar needs.
  3. Start
         with the end in mind. Think: How
         would I do this if I could do it smarter?
  4. Carefully
         plan what you expect to be able to do with the data you get. Do you want to generate reports that you
         already have now? Where does that
         data currently come from? Diagram all the expected data flows and outputs.
  5. Realize
         that you and your banking partners will create limits on what automation
         can do by how much data you choose to include. For example, there is a bank that sends
         out data to it’s customers with essentially 2 codes: Misc Debit and Misc
         Credit, not extremely helpful when you try to automate how these
         transactions are classified
  6. Realize
         when you don’t know something and call people with experience.

How can a vendor avoid selling a stone?

  1. Carefully
         and honestly present what the product can and cannot do. Some pushback from the client is
         OK. Clients don’t always know what
         is possible or available.
  2. Seek
         to truly understand the client’s needs: both current and future state.
  3. Develop
         an excellent hand off from sales to implementation/client services. (this
         is a topic for another blog…or book)
  4. Offer
         timely updates on the progress of the project and the status of
         implementation hours burned. Some
         surprises are not good.
  5.  Provide training that has specific goals,
         responsibilities and timelines.
  6. Carefully
         develop a meaningful  and useful project
         plan. (topic for another blog)
-r


[i] SCORE
is the Standardised CORporate Environment. This is where the corporate is actually a part of the SWIFT network with
SWIFT acting as the hub for messaging to and from any SWIFT bank.

[ii]
MA-CUG is a Member Administered Common User Group. In this SWIFT model the corporate is added as
to specific SWIFT banks via a direct connection for messaging, balances etc.

  

 

Our guest bloggers today attack some common misperceptions about corporate access….

Corporate Access . . . In the news

Asked recently to name the topic du jour in corporate treasury, I immediately went to corporate access.  How corporates connect to their banks is getting increasing attention, especially at the multi-national level.  While it’s not always all about SWIFT (more on that in another blog), their recent offering is gaining traction.

Today there are over 200 corporate users on SWIFT (most in Europe) via a combination of SWIFT participation models.  The uptake has been slow.  This is not surprising given the misperceptions about SWIFT.  Here are the top four (4) misperceptions as we see them:

  1. SWIFT is  well known and understood within the corporate community.
    In reality it’s not.  All too often we hear comments like:  “it’s only for international”; “it’s only for banks” ; “SWIFT only handles payments”.  Obviously, SWIFT is more than this.  It offers true domestic solutions, is not only for banks, and handles much more than just payments.
  2. The SWIFT solution for Corporates is front-end focused.
    Many corporates we speak with are first attracted to SWIFT by the prospect of replacing their multiple front-end connections to their banks with a single interface solution.  While this is indeed a benefit of the SWIFT route, it is only part of the story.
    The real value of SWIFT to the corporate community is no different from the value the banks have enjoyed for decades.  Having a single, standardized messaging environment can enable corporates to build out robust links to their ERP systems.  With this in place, end users can generate and receive messaging quickly, securely, and efficiently.  In short, there is the potential to realize true STP.
  3. SWIFT is only a Treasury Solution.
    It’s not all about Treasury.  When looking at SWIFT, corporates need to take an enterprise view.  True, SWIFT can certainly add value to Treasury.  But, there are other areas within the corporation that can benefit from SWIFT as well. Paying & Receiving, payroll, trade finance, corporate actions, reconciliations, trust services, cash letters, etc., can all be handled within SWIFT.
  4. SWIFT Solution is Complex.
    Well, it can appear to be.  We think it helps to separate the participation models (treasury counterparty, MA-CUG, and SCORE) from the connectivity options (e.g., direct connection and Service Bureau).  There is no “one-size-fits-all” solution here.  The type of participation and connectivity models selected will vary by corporate depending upon their messaging needs.  Having said this, corporates with large messaging volumes will likely benefit most from SCORE with direct connectivity (maintaining their own hardware and connection to SWIFT). 

Guest Bloggers…Randy Marcrum, Managing Director and Ray Mulhern, Senior Advisor-Camino Consulting