In conversation with clients, one topic that comes up time and again is PSD2. When I ask "So, what are you doing on PSD2" there are broadly two responses, "We have it under control" or "We have a team looking at it" swiftly followed by “it can't be much different to PSD". Can it? The answer is quite simply Yes! How much different PSD2 is to PSD is another story altogether and something that deserves a little more time.
Working with Treasury and Sales Desks teams, it's often surprising to hear that many banks are seeing PSD2 as purely a payments/back office problem. In the single currency world that may well be true. However, PSD2 introduces cross-currency payments into the mix, which from a customer’s perspective is no bad thing. As a result of this, there are challenges to overcome and opportunities to capitalise on, for example additional flow through by exploiting the experience of your FX sales team(s).
Last week I was talking to an institution that was well underway with its PSD2 project, its API's were 'under construction' and it had dealt with the FX side of the regulation. I delved further into how it was handling pricing the FX conversion. It became clear that the bank had decided to work off a static rate-card. In the same meeting there were two members of the bank's treasury/sales desk team, whose ears pricked up. The first question was "Why are we still using rate cards?" The response, "It's all our back-office system supports".
The upshot was that an internal meeting was now needed to discuss a 'better' way forward. The FX desk wanted to capitalise on the FX flow; the Sales Desk worried the bank would lose business by not offering a good 'price'; the back-office just wanted a simple solution.
How does this story end? Well, it hasn't yet. My belief for some banks is that PSD2 involves much more than just providing technical APIs, it means looking at business models. For low-value payments, a rate card will probably be enough but for higher value payments a streamed price, backed up with sales desk support, will help get the flow and make sure that the FX exposure can be managed efficiently by treasury teams.
Does this mean one route for high-value cross-currency payments and another for the low-value ones? No. It indicates you need a solution that provides both rate exports and real-time pricing for customer cross-currency payments, FX position management, liquidity protection with full auto-deal capabilities. A high-volume, low-latency solution like siena, maybe?
