Hedging against SEPA Direct Debit refunds

Although it’s now been quite a while since I was involved in Corporate SEPA migration and SEPA has now bedded in for most Organizations, I still occasionally get involved in discussions about specific issues that don’t seem to be as clear cut as others, more-so now that there is another SEPA deadline looming. These deadlines focus the mind and this is when – during implementation rather than theoretical analysis – outlier issues tend to arise.

One such ‘outlier’ is the issue of what happens when a Creditor collects a SEPA DD from a Debtor who is in a non-Eurozone country (or who has a bank account that is in another currency) and where the Debtor initiates a refund 12 months after the original Transaction. Logically, and according to the SEPA rules, it won’t matter. The Creditor simply refunds the Euro amount, regardless of what the customer’s “home” currency is.

But will that leave a happy customer…?

Show me the money … but only in Euro

In a LinkedIn discussion a while back about refunds / reversals (e.g. “R-transactions”) of SEPA Direct Debits, where either the Creditor or the Debtor is in a non-Euro country but the SDD is processed in a Euro denominated transaction (as all SEPA transactions must be), it was pointed out that there may be mechanisms in place to take currency exchange rate fluctuations into account – specifically the difference in exchange rate at the time the SDD was collected compared to when an R-transaction might be processed – perhaps as much as 13 months later.

This is a fairly uncommon scenario, I suspect, but it’s the uncommon scenarios (i.e. outliers) that make for the best ‘what if…?‘ questions and that, of course, is where we Business Analysts love to play… 🙂

Why should I pay for your mistakes?

I have been personally affected by this sort of thing three times in the last 12 months, albeit with Credit Card transactions rather than SEPA DDs but the result is the same. In all three cases, the currency exchange fluctuation between initial transaction and subsequent refund meant that I lost out financially. As a customer, I paid in Euro and the refund to my Credit Card appeared as Euro, but the refund each time was less than the original payment because the other party was conducting its business in Sterling or Dollars.

In all three cases, these were car rental companies and in all three cases they overcharged or falsely charged my card and subsequently admitted this (i.e. their fault, not mine) but it still cost me money. In one case, the difference between what was charged (STG £600+) and what was refunded cost me around €50. You can be sure I won’t be using either of those companies again (Hertz at Glasgow Airport and Dollar Rental at JFK, in case you’re interested… I might write a Blog post about these & similar incidents at some point…).

Anyway, as you might imagine, I’ve been thinking about this particular issue quite a bit lately and I wonder how it might be handled in high-frequency, low-value payments processing situations where the Creditor really wants to maintain their relationship with the Debtor. I’m particularly interested to hear if anyone knows how this issue is actually being handled – if at all – by the more customer focused Corporates in SEPA-land…

It occurred to me that there is an obvious gap, and therefore an opportunity, whereby a sort of “Hedging As A Service” could be offered. Take the following (very contrived) example…

• Corp_A sells a product for £100. Cust_B decides to buy it, paying with a SEPA DD from a Debtor Account denominated in Euro. Assume the exchange rate is £100 : €125. Therefore, Cust_B pays €125 and Corp_A receives £100. Everybody is happy.
• A year later, for whatever reason, there is a requirement to process a refund. By this time, the exchange rate is changed, and is now £100 : €150 or, from another perspective, £83.33 : €125
• The original amount debited was €125, so this is the amount that must be refunded in the SEPA R-Transaction.
• It turns out that Corp_A is in profit – in their own currency – because of the FX rate fluctuations between SDD and R-Tx dates. Of course, for Corp_A to be in profit on the transaction, then Cust_B must be at a loss… even if only a nominal loss because of the ‘opportunity cost’ of the money over the intervening period.

 

Ah, yeah… but…

Of course, the reverse would also be the case.

Assume the rate had gone to £100 : €100 instead. In that case, in order to return the Euro amount of €125 to Cust_B (as required by SEPA rules), Corp_A would have to pay £125 . Then, Cust_B would receive the money they paid (so there’s no real ‘happiness’ factor to consider) but Corp_A would have incurred a substantial loss on the overall transaction. There’s almost no way that Corp_A would refund the non-Euro amount (as happened with my Credit Card transactions). SEPA rules don’t permit it. At least, not at the moment. Even if the rules did permit it, imagine the Customer’s fury when their refund is short-changed (as mine was with Hertz & Dollar)…

In some payments processing systems, Creditors have arrangements in place to ensure the risk is minimised. For example, payment specialists Sentenial have previously advised that they can facilitate a sort of ‘side channel’ transmission, between Banks, of the FX rate on SDD collection date. This data is then used to recalculate, on R-TX date, what the rate would have been on SDD collection date. I’m not sure what the advantages / disadvantages of this approach are to end users (i.e. Ultimate Creditor and Ultimate Debtor) but it shows that there are channels – at least in Sentenial’s products – to transmit the information that would be required to automate some consistent solution.

I’m not sure I can see how this would get around the fact that, if a SDD is processed on a given date and it involves cross-currency FX to calculate the Euro amount, and if this amount changes between SDD collection date and eventual R-TX date, then both sides of the TX will be affected for (equally? Zero-sum?) better or worse. At least the Debtor is protected *in Euro* (apparently) against losses due to FX fluctuations – but is also shielded against any potential gains.

 

I need a dollar, dollar is what I need… not a Euro

Now, as if to make it even more complicated, what happens when BOTH parties who want to use SDDs are outside the Euro zone…? Well, exactly the same… but different and twice as bad!

• Assume Cust_A is in the USA and the money s/he uses to pay for the £100 item was originally in US$. This amount must be (nominally, at least) converted from US$ to £, to get the appropriate amount. This amount must then be converted to € to find out how much to collect in the SDD.
• If and when there is an R-TX, it will be for the € amount. It must then be converted back to £ by Corp_A so it knows how much will leave it’s own accounts. When the amount is converted back to US$, it will almost certainly be different to the amount that Cust_A initially paid.
• Confused…? Not as much as the Debtor who paid one amount and later got a ‘full refund’ that was for a higher, or lower, amount!

Hedging your bets

Of course, there is nothing new in all of this… that is, if you are a multinational, multi currency Corporate who is accustomed to taking FX fluctuation – and, consequentially, FX Hedging – into account in your operations. For the rest, the potential 13 months during which an R-TX might arise will be a FX risk period. Assuming, of course, you want to keep your customers happy and don’t want to refund them an amount lower than you originally charged them (which is, of course, exactly what Hertz and Dollar rental did to me, through no fault of my own, and lost any of my future business because of it).

Maybe there is an opportunity here for the multinational, multi currency Corporate (especially those who took SEPA migration as an opportunity to rationalise payments and/or implement any variant of a ‘Payment Factory’-type system) to offer to ‘insure’ against possible variations in the R-TX amount, hedging the risk of having to pay more of the ‘local’ currency, (to match the R-TX amount) against the possible gain of having to pay less…

It’s confusing enough even trying to explain this stuff, without having to figure out how to implement automated, consistent solutions to handle these outlier scenarios.

Then again, that’s what we Business Analysts are for 🙂