Transparency: fees, rates and time in the open

Transparency is the direction in which cross border payments are moving, driven by regulation, by competition from fintech companies, and by customer expectation. In the past, a customer who sent money abroad was told the amount to be sent and the charge of the sending bank, but was not told the exchange rate, the spread, the charges of the intermediary banks, or the time the payment would take. Regulators in Europe, the United Kingdom, India and elsewhere have responded by requiring banks and payment providers to disclose the full cost upfront, including the exchange rate, the spread, the charges, and the expected delivery time, before the customer confirms the payment. In the European Union, the Payment Services Directive, PSD2, requires the payment service provider to disclose the total charges, the exchange rate, and the amount the beneficiary will receive, before the customer confirms the payment. The directive also requires the provider to give the customer a receipt with the same information, plus the reference that identifies the payment. In the United Kingdom, the Payment Systems Regulator has set rules on the transparency of cross border payment costs, and has required providers to publish the cost of sending money to common corridors. In India, the Reserve Bank requires banks to disclose the charges and the exchange rate upfront, and to give the customer a receipt. The transparency rules change the design of the payment journey in practical ways. The payment screen must show the amount to be sent, the exchange rate, the amount the beneficiary will receive, the charges, and the expected delivery time, all before the customer confirms. The confirmation screen must repeat that information, so that the customer has a record of what was agreed. The receipt must show the same information, plus the UETR, so that the customer can track the payment. A business analyst who designs a cross border payment product must build these disclosures into the requirements, must test that the amounts shown are accurate, and must ensure that the rate shown is the rate applied, not a rate that changes after confirmation. The expected delivery time is the hardest disclosure to get right, because it depends on the correspondent chain, the cut off times, the time zones, and the compliance screening. A payment instructed on Friday afternoon in India for a beneficiary in Brazil may not arrive until Tuesday, because of the weekend and the time zones. A payment that is stopped for a compliance query may take a week. The analyst must therefore show a range, not a single date, and must explain the factors that can delay the payment. The gpi tracker helps, because it shows the actual status, but the upfront promise must still be honest. A bank that promises one day and delivers in three will lose the customer's trust, even if the payment itself is correct. Fintech companies have pushed transparency further by offering a single upfront fee and a rate close to the mid market rate, and by showing the delivery time as a range with a high degree of accuracy. Banks have responded by improving their own disclosures and by adopting gpi, which gives the transparency on the journey that fintechs offer on the price. The analyst should study both models, the fintech model of a simple upfront price, and the bank model of a gpi tracked journey, and should design a product that combines the best of both. The customer does not need to understand the correspondent chain or the nostro accounts, but the customer does need to know what they are paying, what the beneficiary will receive, and when it will arrive. There is a specific transparency problem that the analyst must watch for: the rate shown is not the rate applied. Some systems show an indicative rate on the payment screen and apply a different rate when the payment is processed, because the rate moved in between or because the system uses a different rate source. The customer is then charged more than was shown, and the complaint is difficult to resolve because the bank cannot prove what rate was shown. The analyst must specify that the rate is locked at the point of confirmation, that the locked rate is stored with the payment record, and that the receipt shows the locked rate. The test pack must verify that the rate on the receipt matches the rate on the confirmation screen, for every payment, not just for a sample. The analyst should also design for the case where the amount the beneficiary receives is different from the amount shown. This can happen when an intermediary bank deducts a charge that was not disclosed, or when the exchange rate moves, or when the beneficiary bank deducts a charge. The customer must be told, through the gpi tracker or through a notification, that the amount changed and why. The notification should show the original amount, the new amount, and the reason for the change, in plain language. A customer who is told that USD 40 was deducted by the correspondent bank and is shown the charge will accept it. A customer who discovers the deduction by checking their balance will complain. Transparency after the payment is as important as transparency before it.