Living abroad, with tokens.
I have just completed a three-month stint building our business in Australia, and expect to return for a similar period in the near future. How were payments, for me? The first thing to note (to coin a phrase) is that I used no cash whatsoever and don’t recall seeing anyone else either. All retail payments, including transport payments (don’t knock commuting if you’ve never travelled to work on the Manly ferry), were via my Apple Watch, so no PINs, either. (Australia is online PIN, so if you do use an old-fashioned card, you’re unlikely to ever have to insert it into a reader.)
Of course, virtual cards, as wielded by (for example) Apple Pay and Google Pay, present tokens (Device PANs) as an alias for the Primary Account Number (PAN). This ensures that the issuer is able to block fraudulent transactions that could present the Device PAN from somewhere other than the relevant wallet (for example, during a standard e-commerce checkout).
Living and working abroad for three months requires payments for things beyond the usual touristic or business travel items—for example, rent and utility bills. Credit cards are not particularly well suited to many of these payments, with the requirement for recurring (and, sometimes, variable) payments, returnable deposits and so forth. Further, in Australia, it is standard practice for credit card payments for these kind of transactions to attract hefty surcharges. And, of course, forex charges and spreads apply.
What would have been better, would have been to have an Australian bank account and use all the domestic money transfer facilities. The trouble was, I didn’t have much idea of eligibility criteria (such as long-term residency) or how long KYC checks would take (especially without an Australian Tax File Number or driving licence, etc). Fortunately, there is a partial solution.
A number of fintechs (I used Wise) enable you to set up an account in your home country and then create (or have created, automatically) linked accounts in many other countries. Thus, I acquired an Australian BSB (Bank-State-Branch, equivalent to UK Sort Code or US/CAN Routing Number) and Account Number, exactly as any long-term resident.
In essence, the BSB/Account Number combination is a token representing my (UK-based) relationship with Wise. Just like a Device PAN, it enables a class of transactions, using a convenient digital representation; and also limits the scope of transactions; e.g. preventing anyone misusing the token from raiding my Sterling or US dollar funds.
One current limitation is that I cannot use the Australian bank details to set up a further level of indirection, that is, to use an Australian PayID, which would enable me to use a convenient handle, such as my mobile number, in place of hard-to-remember bank details (and, in fact, enable account portability). As well as providing more convenience, like other forms of token, this improves security, by making it less likely that someone impersonating me, and requesting payment, can pass off bank details which they control.
It would be nice to go one further step, which would be to use PayTo, the service set up by Australian Payments Plus, using the New Payments Platform (NPP), to manage payment relationships via mobile apps provided by banks and fintechs. I hope Wise (and others) are working on that. Then, a digital nomad could truly fit in!
Finally, a related grouch: I was frustrated, on a number of occasions, by useful apps not being available to people, demonstrably present in the relevant country, with an Apple ID associated with a different country. One example was my mobile provider; the obvious way to top up an account would be via their app, on a phone carrying their SIM, one would have thought. It was not to be, unfortunately. The same issue occurred with a government app and a newspaper app. Conceivably, I could have created an additional Apple ID or temporarily changed my residence details on the existing Apple ID. You’ve got to me braver than me to do that!
Here at Consult Hyperion, we are often involved in design implementation and testing of secure systems on devices such as smart cards and mobile phones for payments, banking and other applications where security is critical.
We were delighted to get a lot of good feedback on Neil’s previous blog on Mondex Memories and CBDCs and its relevance to CBDCs and thought it would be interesting to respond to some of the more interesting – and difficult – points raised in a follow-up blog. Before addressing those I wanted to put the Mondex program into some historical context. They were very different days – we didn’t have an intranet until 1996, let alone internet access. There were no SDKs – although actually we did build a precursor to one of those – or APIs and the idea of remote payments was still in its infancy (although we did that too).
For most of us 2020 isn’t going to be a year to linger fondly in the memory. It’s been a monumental slog in the face of grim news and little cheer but from a payments perspective we’ve seen an unsurprising surge in interest in all things payment related.
People have moved from cash to electronic payments – contactless transaction numbers have soared. People moved from face to face purchases to online. And, there’s been a ton of stress on payment systems as people have demanded refunds for holidays and flights they couldn’t take due to various travel restrictions. It’s been a year like never before.
We can expect this to be exacerbated over what will likely be an extended Black Friday and Christmas holiday shopping period. Online payments are expected to grow even though economies are in recession. For us in Europe it’s the last hurrah before PSD2 requirements on strong customer authentication come into force on January 1st. Merchants and payment companies will be well staffed on News Year Eve as they wait and see how the systems will hold up, and what sort of abandonment figures they’ll see as puzzled customers are presented with confusing authentication screens. We can probably expect a flood of concerned calls about phishing which are actually Strong Customer Authentication requests.