Snippings

xxx

Chargebacks for card-present transactions increased 50% following the Oct. 1 EMV liability shift,

From EMV Chargebacks Proving To Be a Card-Present Merchant Problem

You understand why this, I assume. It’s because before 1st October, if you spotted a $3.95 charge at Starbucks on your statement and you knew that you couldn’t possibly have made that transaction, then you would call up your issuer and complain and they would just eat the charge because it would have been more trouble than it’s worth to go back to Starbucks, pull the receipt, check the signature if there was one etc etc. However, after 1st October, if you spot a bogus $3.95 charge on your account and call up, the issuer will check the transaction codes and, if you had a chip card but it was swiped by a merchant who didn’t have (or didn’t use) a chip reader, then the $3.95 is charged back to the merchant. The net result is — entirely as expected and as it should be — that merchants see big increases in card-present chargebacks as previously hidden magnetic stripe fraud is revealed.

xxx

Essential information for the ASPSP to make an informed authorisation decision when prompted with a payment or account information request from a TPP consists of:

What is the functional scope of the transaction? (what payment needs to be executed or what account information needs to be provided and to whom?); Did the person requesting the transaction, actually consent to exactly this functional scope? and Who is the person requesting this transaction? (and is he actually a mandated ‘controller’ of the respective account?)

Of

From Banks taking liability for XS2A transactions: ‘Just because a TPP says so?’

xxx

The European Central Bank (ECB) interest rate for bank deposits is currently minus 0.3% and economic theory would predict that at a minus rate, depositors (and this includes companies as well as banks and individuals) would prefer to hold cash rather than pay the central bank to look after their money for them. It has to be said that this doesn’t appear to have happened on a large scale yet, but clearly one of the reasons why economists are interested in getting rid of cash is in order to allow the interest rates to go further into negative territory in order to stimulate economic activity over hoarding. Now, it clearly costs something to manage cash over and above the cost of managing an electronic deposit hence it is interesting to speculate what the crossover rate might be, the modern version of the old “specie point” at which it was cheaper to hold bullion for monetary purposes rather than paper instruments.

In Germany, this calculation is being made. The Bavarian Savings Bank Association sent around a circular to their members setting out their version of the calculation. On this basis, the crossover rate is actually about half of the current negative rate: we’ve already crossed the crossover point.

With 1.50 euros plus insurance tax for 1000 Euro, the value would be at 0.1785 percent, below the ECB’s deposit penalty rate of 0.3 percent, it said. Additional costs for CIT or additional burglary protection are not taken into account.

From Penalty interest: Unions want money rather stash in the vault – SPIEGEL ONLINE

 This isn’t really a serious calculation because, as it says at the end, it doesn’t take into account the significant costs of cash in transit (CIT) or the additional security expenditure that would be needed to guard cash hoards. But it does make a fun point, at least to me, which is that the existence of the €500 notes has an impact on that crossover rate. Clearly, if the maximum denomination banknote in Europe was (as it should be) €50 then you will need 10 times as many of them to create a horde of the same value and that means higher costs for storage and transport. Now that the ECB has decided stop printing the 500s, banks would have to store masses of 200s, so the cost of storage and transport will be even higher.

Nevertheless, the calculation does make an interesting point, which is that we appear to past the crossover point already, yet no banks have to date decided to store their squillions under the mattress rather than leave them on deposit. Oh, wait…

Commerzbank, one of Germany’s biggest lenders, is examining the possibility of hoarding billions of euro in vaults rather than paying a penalty charge for parking it with the European Central Bank, according to sources familiar with the matter.

From RTÉ Mobile – Commerzbank may hoard cash to avoid ECB charges

Why on Earth would they want to do this? Does it really make any sense?

xxx

I posted a screenshot of the email, and a few lines about how I would not be using Twitter until they figured out how to stop making incidents like this one (gross, but comparatively benign) a less constant component of my Twitter experience.

From Twitter Has Become a Park Filled With Bats — Following: How We Live Online

xxx

xxx

[Money] may become as David Birch has suggested synonymous with identity itself. The value of such personalized forms of currency- which is really just a measure of individual power- will be in a state of constant flux.

From The Future of Money is Liquid Robots

This does not seem an unreasonable prediction.

With everyone liked to some form of artificial intelligence prices will be in a constant state of permanent and rarely seen negotiation between bots.

From The Future of Money is Liquid Robots

xxx

xxx

[Venmo] noted that it just doesn’t have the resources to support the API anymore, as it’s too busy working on its new peer-to-peer platform and its in-app payment service

From Mobile App Reviews: Venmo Kills Off API for New Developers

xxx

xxx

The market for media of exchange will gravitate towards those systems with the lowest transaction costs, and in the case of proof-of-work digital currencies, that means those protocols that forever subsidise hashing costs with the coin’s seigniorage

From Some Crypto Quibbles with Threadneedle Street | cryptonomics

xxx

xxx

This job has been largely been left to the European Banking Authority (EBA) who have been mandated to define the necessary guidelines and regulatory technical standards (aka RTS – although they won’t be defining anything ‘technical’ as technologists might understand that term) which are subject to their own timelines.

From PSD2, why the confusion? Oh, that’s why! | Killian Clifford | LinkedIn

xxx

xxx

Let’s say you like the look of a house that is for sale. You judge it is worth – for argument’s sake – 100 rupees. The chances are the seller will tell you he will only take, say, 50 rupees as a formal payment and demand the rest in cash… It means the seller can avoid a hefty capital gains tax bill. Buyers benefit too because the lower the declared value of the property, the lower the property tax they will be obliged to pay.

From How ‘black money’ saved the Indian economy – BBC News

This means that Indians tend to have much smaller mortgages compared to the real value of their properties than elsewhere in the world and hence the system is more resilient against shocks to the system. Of course, the system concentrates wealth with rich people who can afford to pay cash, but the point made in the article holds.

OK, so fair enough, I was a little disappointed. The Open Banking Working Group published its Open Banking Standard.

The Open Banking Working Group, which undertook a review last year at the request of the Treasury, is calling for information on banks’ products and customers to be more easily accessed by digital services, including comparison sites.

From Banks urged to share data so customers can shop around – FT.com

Right underneath the heading “Open Banking Standard”, the document says that its goal “in publishing this Framework today is to enable the accelerated building of an Open Banking Standard in the UK”. Wait, what? We went from a “standard” to “a framework to accelerate the building of a standard”? This is why I was disappointed, to say the least. I thought the document might set out some actual APIs so that that both banks, fintechs, regulators and entrepreneurs could plan new products and services but the truth is  it reflects the political realities of the pending complex “settlement” between banks, the regulators and others. It’s a holding document.

Here’s what I mean. Many people thought the document was going to say something along these lines…

The EBA DCSI three-part framework for PSD2 XS2A looks good so we’ll use that. The EBA can set the mandatory payment APIs. We will define a minimum set of non-mandatory payment APIs specific to the UK (to use, for example, PayM). We will also define a minimum set of non-mandatory non-payment APIs (i.e., the Treasury standards for Open Banking) specific to the UK but in consultation with relevant European bodies.

Now, I am particularly interested in the non-mandatory non-payment APIs, including those for Open Banking, because that’s where I think that the banks have an opportunity to become an essential platform. I was expecting to see a list of proposed APIs along the lines of…

DCSI_NMNP_UK_Adult ( Service Provider, Customer ) returns { YES, NO, INVALID_PROVIDER, INVALID_ACCOUNTHOLDER }

I’m not that interested in open data (e.g., ATM locations). What I’m interested in is customer transaction data, especially as it supports the more transactional APIs envisaged under PSD2. It would be crazy for banks to have to implement multiple infrastructures, so it’s logical to create an infrastructure for access to customer transaction data that can also be used for transactions. To use an obvious example, working out how to get the Service_Provider token and the Customer token is actually pretty complicated. If we can figure out how to do it (evolving the security standards as we go, in line with SCA) so that customers can access their own transaction data to start with (and, of course, to grant that permission to third-parties) then we can have an enabling platform in place for PSD2 that ought to turbocharge the fintech sector, as well as the banks (as I wrote earlier this week, banks will be users of these APIs as well as providers of them).

Anyway, let’s move on, since the Standard did contain any APIs or even a framework for APIs, we can’t use it to start planning services right now. Let’s instead focus on the positives and look at what the document did. What it did set out was a four part framework, comprising

1. A data model (so that everyone knows what “account”, “amount”, “account holder” etc means);
2. An API standard.
3. A security standard.
4. A governance model.

None of these currently exist, so they need to be created. If we focus on the APIs, the document does note that thanks to the requirements of the Second Payment Services Directive (PSD2) and the General Data Protection Regulation (GDPR), many of the APIs will need to be built anyway. Hence co-ordinating the APIs in this way will actually save the industry time and money and obviously we all agree with this. But it looks as if we’re going to have to wait before we start prototyping and testing any actual apps for this stuff.

Of particular interest to me (and to many of our clients, I imagine) is the relationship between token provision and strong customer authentication (SCA). What are the flows going to be? So the document didn’t really get interesting for me until page 48, where Figure 7c.1 sets out the authorisation flow: third-party requests access to data, customers authenticates with bank (under provisions of SCA, presumably), customer is returned to third-party provider. Sounds easy, doesn’t it? It isn’t. As the Standard explains, there a significant risks around this. I can paraphrase them easily as:

1. Grandma sees a page from Age Concern asking for access to her bank account;
2. Grandma grants access to Eastern European fraudsters or, worse still, investment bankers;
3. Eastern European fraudsters or investment bankers loot Grandma’s account.

How does Grandma or, for that matter, anyone else know that who they are granting access to and what they are granting access for actually corresponds to what is on their computer screen? Well, as Figure 7c.3 indicates, they can’t. Hence requests for access can only come from organisations that have been registered previously with someone, in some way. I guess they are thinking about registering with an Open Banking Authority or something like? I might also point out that where the document talks about Grandma giving “informed consent” I automatically shiver. Having been involved in a couple of previous projects for the European Commission to try to explore what “informed consent” actually means and how the general public might be supported in giving it, I can tell you that it is a minefield (I can imagine the lawsuits might make Payment Protection mis-selling look like a walk in the park.)

I agree very strongly with the document about contextual limitations. The tokens granted to third-parties should be circumscribed. They should be for a fixed time, for a fixed purpose, for a fixed provider. So if I give Saga permission to look at my bank account, that permission should be for (say) 7 days maximum, read-only and only for transaction data.

There is some technical detail in the Standard. It says that APIs should use JSON/REST, for example.

However, there are a number of leading API platform providers and no universally accepted RESTful API design methodology, which will lead to a scramble by the proponents of RAML, SWAGGER and Apiary.io to be the provider (and language) of choice for creation of common open APIs and developer sandbox.

From Celent Banking Blog » The UK open banking API framework – more questions than answers?

xxx

The data accessed via an open API may be closed, shared or open data.

xxx

Permission to access data will only be granted on the basis of informed customer consent,

The document calls for the launch of, in a year’s time, of a

tightly scoped Open Banking API, enabling select, read-access, open data use cases

Now, let me stress that I was not party to any of the discussions, and I am not breaking any confidences by saying this, but I imagine the discussions about what data the banks consider “proprietary” and what data the banks consider “open” must have been rather convoluted.