Should be read in conjunction with The Outsourcer’s View – An Interview with Unisys and How can we make substantial cost reductions to Europe’s Payments?.
This example uses foreign currency payments based on the correspondent banking model. This area is one of the most standardised but savings can still be made. The diagram below illustrates the key elements based on the abstract architecture previously used. See Payments System Structure.
Let us analyse the cost saving opportunities according to the three classes of rationalisation described in How Cost Savings Can be Achieved.
A. Rationalisation of Hubs
No opportunity as SWIFT provides a worldwide hub for these messages already.
B. In Country Rationalisation of Bank Functions
Lots of room for cost cutting here; in particular:
- Error handling; is a very manual process, largely invisible to customers; it deals with incoming payments where the payee information is inadequate for straight through processing.
- Customer communications; email, fax, and postal communications could easily be centralised and automated, not so true for call centre queries which would have to coordinate with more general customer support (e.g. branches).
- Formatting payment instructions; lots of cost in verifying outward payments instructions are correct and available funds are in place prior to release, particularly for fax, phone and postal instructions. Inward payments need to be converted into in country payment types; lots of room for rationalisation of this activity.
- Most banks have home written software for this whole area of payments activity, or low function extensions to their banking packages. There is an opportunity for a Software vendor and/or outsourcer to convert this activity to a common platform and hence reduce costs.
C. Cross Border Rationalisation of Bank Functions
Because the Foreign Currency Payments are defined by SWIFT messages a very large part of the In Country Bank Rationalisation is extendable across borders. Parts that would be more difficult would be:
- Error Handling; greater knowledge of each country’s account numbering and inter bank query systems. However, since this is all “behind the scenes” work it should be reasonably achievable.
- Customer Communications; the emails and fax responses could be customised for language, etc. The phone based customer contact would not cross borders very easily.
- Formatting Payment Instructions; for inward payments knowledge of each country’s local currency payment systems would be required but again this is all “behind the scenes” activity so should be achievable.
The target architecture for this payment type is show in the diagram below.
There is not much to stop a few banks and/or an outsourcing company with a bit of gumption starting this right now. The interfaces to the bank are relatively few and simple. It would, however, be greatly assisted by a standard interface from the payment interface points and the obvious standard is some variant of the existing SWIFT messages.
Apart from the quite large manual costs associated with these payment types, there are significant systems maintenance costs caused by the constant changes in the regulatory environment, (OFAC checking, SWIFT standards, Money Laundering legislation etc.).
