Community

Payee confirmation was the first of my Five Ways to Stimulate Electronic Payments. When I was involved in the implementation of FPS for a Top 5 UK bank, I was told that this feature can't be supported because it would be tantamount to one bank coming to know another bank's customer information.

Not sure whether this is a genuine interpretation of customer confidentiality laws in UK or yet another cock-and-bull story told by banks to justify status quo instead of taking steps to improve CX.

I had a torrid time linking just one Aadhaar # to a bank account.

Linking Aadhaar Number To Bank Account

Good luck linking multiple #s!

@AFinextraMember:

TY for your clarification. I assumed sequential meant incremented by 1.

Any idea why FCA would need to contact British lenders to see "if they too are using a sequential numbering scheme for their cards"? Since they must all be generating their numbers using some algorithm, isn't it obvious that they're indeed using a sequential numbering scheme?

How's this possible? I thought V/MC rules require card numbers to be compliant with MOD 10 / Luhn algorithm, which ensures that they won't be sequential?

@TomHay + 1. "Incumbent power", I guess!

Facebook has already told Admiral, effectively, that what happens on FB should stay in FB - and not be used to calculate insurance premium. Now this warning from Fed. Let's see where this goes...

Nice post. I also read recently about a pilot in which a bank used RFID tags on shipping containers. As and when the consignment crossed a gantry, an update was posted automatically on a blockchain-based Supply Chain Finance system. So far, the consignment sighting step, which is an integral part of the SCF chain, has been done manually. High time we used technology to nudge it past the era of physically sighting camels!

On a side note, your 2/98% example is interesting. I've a bit of payments background. High touch payments have been digitized for 10+ years. Surprisingly, they still have 1-2% error rate, which also entails considerable manual repair costs. This is likely due to inherent design flaws in the payment flow architecture and / or operational mistakes driven by inferior CX in the payments processing systems. IMHO, SCF digitization should avoid repeating similar mistakes.

No, I won't use GoldCoin. Because I'd be better off with BitCoin and gold.

As for transacting, BitCoin already enjoys greater ubiquity compared to "yet another virtual currency" like GoldCoin. That GoldCoin is backed by gold doesn't really matter to me. All I need from my currency is the power to transact i.e. of being exchanged for some desired product or service. BitCoin - and half a dozen other virtual currencies - are miles ahead of GoldCoin on that count.

As for storing wealth, I'd prefer gold itself. When a nation's legal tender can be declared illegal by half a dozen leaders overnight - rightly or wrongly is besides the point - I'd prefer to hold my wealth in a form whose value can't be decided on the whim of a few people but is widely acknowledged by a vast majority of people. I'd certainly not want to hold it in yet another virtual currency like GoldCoin that can vanish in seconds because of a bug in some software.

If different fraud detection systems at different banks can cause the observed difference in "hackability between the two cards, then, IMHO (a) it's a bit irresponsible to tag the hackability difference by V / MC; and (b) a bit naive to select two such banks in the first place for conducting this test.

If anyone from the testing team needs any tips on finding a single bank that offers both V and MC cards and manages both of them on the same card management and fraud detection systems, they can feel free to contact me.

Why is this study silent on the time taken to crack the cardholder name? I don't know too many websites that allow an online card payment to go thru' without that piece of info.