Community

@FinextraMember @ 14:26:

Had somebody asked me when I was lead for FPS implementation at a Top 5 UK Bank in Sep 2007 when FPS would go live, I'd've said confidently Nov 2007 (Memory serves the date was 7th). But we all know what happened and when FPS actually went live.

It's not just then. We recently learned that SCA deadline has been pushed back by ~18 months. And we don't even hear much anymore about once-upon-a-time hot topics in payments like Enhanced Remittance, Confirmation of Payee, etc. So you'll kindly excuse me if I'm a bit skeptical about deadines of payment projects.

I said "20121 20126, ... " - not 2021 2026. That's how your comment appeared / still appears to me, as you can see from the screengrab I've posted here. 

@SakibSheikh: 

TY for your detailed response. Obviously Sender and Receiver of the payment can't "educate and support banks in improving their data practices". I leave that to your firm's able hands. BTW, the way I understand the specific incident referenced in my above comment, it was the Originating Bank (not Intermediary) who told the Sender (my Customer) that the full name of my company won't fit, so some truncation is required, and it was the Sender who replaced PRIVATE LIMITED with INC. Said education of banks needs to be done ASAP since the originating bank in this case squarely blamed SWIFT for the field length limitation. 

@FinextraMember @ 11:12:

20121 20126 just a little over a year away - LOL how odd is that?

Reminds me of 15 years ago, when my team had told me, ISO20022 was "a year away" and we needed to urgently rewrite one of our company's software for the new standard. Thankfully, I didn't take it at face value, otherwise, I'd have added one more finserv tech solution looking for a problem. 

Had you read my comment more fully, you'd have realized that the international payment was initiated by my customer's bank in the USA. Me changing my bank is not going to solve the problem. 

Thanks a ton but I strongly suspect the bankers concerned, at either or both ends, don't know half of all these details of SWIFT! Yes, as I too mentioned, it's a problem with field length but bank attributes to SWIFT, so who knows. I've been hearing about ISO20022 for ~15 years. High time I added it to my Fintech Waiting for Godot list:) 

Delay is bad but the proposed move to delay first time payments by 24h is not as harebrained as it's made out to be.

We've waiting for digital identity like Samuel Beckett's protagonist was Waiting for Godot. Even if one existed, I doubt if it'd be any easier for the lay Payer to verify the digital identity of the Payee than it is to verify their real world identity. As we've seen, Confirmation of Payee is harder than first imagined and its implementation is delayed to next year. When I was involved in FPS implementation, I recall a scheme rule that said Receiving Bank would face a penalty if it failed to credit a payment to Payee's account within 2 hours (or was it 15 seconds?). So far there's no evidence that APP fraud involves a single account receiving multiple credits in a short while. Besides, there are several genuine businesses (e.g. events) where it's perfectly normal to receive multiple credits into an account in a short duration. Holding Receiving Bank responsible is not a solution. 

End of the day, APP fraud is caused by Payers being careless. Best solution is to educate them to be careful. Since such Payers constitute vote bank, lawmakers won't have the guts to tell them they won't get bailed out for their carelessness. Against that backdrop, delaying payments by 24h is perhaps the next best solution. 

I recently told my customer in the USA to transfer the payment to my company, GTM360 MARKETING SOLUTIONS PRIVATE LIMITED. His bank's cross-border fund transfer system didn't support such a long payee name, presumably because SWIFT, the underlying messaging platform, didn't. He thought PRIVATE LIMITED  was the US equivalent of INC and changed the payee name to GTM360 MARKETING SOLUTIONS INC. The money came to my bank in India, where it was rejected because of mismatch in payee name.

I say this was a failure in SWIFT system. I'm sure SWIFT would claim it was caused by "incorrect data inputs". 

How to settle this debate?

24h delay in FPS payments would slow down online ecommerce and bill payments, leading to a day's delay in shipment and due dates of utility payments etc. As far as I can see, we can live with that. However, such a delay would effectively kill the use of FPS-based payment methods for instore payments at supermarkets and other brick-and-mortar stores. 

Yo @FinextraMember at 18:42: Hope you're right! If so, it will restore my faith in free market capitalism. Especially since it would prove that buyers still have power even under an alleged monopoly / duopoly situation.

Uh oh, a year ago, I'd lauded Kroger's move here. Sad to say its gambit didn't play out. I strongly suspect that the retailer got carried away by the fintech buzz and tried to find alternative payment methods. And realized, as we've seen repeatedly over the last decade, that there just isn't any cheaper alternative to credit / debit cards that are equally popular with consumers.

While the ability to deposit funds into drivers' bank accounts as soon as the ride is complete could be a competitive advantage, it would also mean Uber loses the float it used to enjoy by holding on to the money in its own account for a few days (or weeks as Uber drivers in India have recently started complaining). This would tend to push the loss-making Uber further into losses. Hope the company has a plan to prevent that from happening. Wall St seems to be losing patience with loss making tech giants these days.