@Bradley It's a 2-factor authentication where the SIM in the mobile phone is used for the authentication process. The PIN is used to access the SIM. So its not a replacement of a password by a PIN. Because a mobile phone (SIM) is required to authenticate, it is a significant higher security level than only a password that can be stolen or intercepted. I only do not understand why it is not possible to scan a QR code instead of entering phone number. If this mechanism could be lifted to a European standard, the economic value could run into billions of euros (reduction of fraud, improvement efficiencies).
14 Sep 2017 21:04 Read comment
@Robert : I suggest to make a distinction between guaranteeing of payment and crediting of beneficiary account. A card (authorisation) transaction is guaranteed by the debtor bank and in order to do so it carries out the fraud check and debits the customer account/makes a funds reservation before a confirmation is sent back to the merchant. That is most relevant for the merchant to hand over goods to the buyer. The actual funds are received days later (may be annoying, but not business critical). If a payment is not executed because of AML, the merchant needs to take it is not on the AML list. If a merchant is on such a list, it becomes hard to business anyway as you are not supposed to receive any (electronic) payments irrespectively they are PSD2 initiated or not. In case of instant payments and an AML check is applicable (mainly applicable for cross border), this needs to be carried out by the debtor bank before the payment is sent to the instant payment CSM. In case of possible suspect and further investigation is needed, the instant payment needs to be rejected unless resolution can be carried out within the instant payment processing timelines by making use of artificial intelligence (IBM recently announced a solution to make this possible).
05 Jul 2017 09:29 Read comment
Unclarity on the status of the response, that is returned by a bank on a payment initiation API call, is a much bigger issue for TPPs and Fintechs. If this status does not imply a commitment of the bank that the payment is guaranteed, the PSD2 API is not suitable to pay for online and in-store purchases (where it essential to know as a merchant that you are going to receive the money in order to hand over/send goods). Taking into account that one of the key reasons to launch XS2A by EC was to increase the competition on the card brands (besides the cap on interchangre fees). Without a guarantee of payment, it is very unlikely many merchants are going to accept PSD2 enabled payment instruments.
30 Jun 2017 22:20 Read comment
Absence of service level specification of the PSD2 API services is a gap in PSD2 at the moment. It is not only availability, but also response times and the maximum numer of API request one TPP can send in per second. In addition it is recommended to specify what the response of the payment initiation implies. Does that mean the payment has been received, payment is validated and is going to be processed, payment is guaranteed and fraud check, AML check and funds reservation/debit have taken place so that the payment can't be rejected anymore by the debtor bank. If the end user buys a product in a store (or online) it is relevant for the merchant to have the guarentee it is going to receive the funds because as it will be handing over the goods which is irreversable. If this is going to be different from bank to bank the relevance of PSD2 may become significant less.
29 Jun 2017 07:32 Read comment
Many banks in Europe already use a 2-factor authentication and if not, need to have it implemented when RTS comes into force. This makes screen scraping a very (end-)user unfriendly exercise. It is not possible anymore to leave a userid/password with TPP as 2FA requires an action from the end-user with a specific device that only the end-user has access to. This means that each time a payment is initiated or account info is retrieved through screen scraping an action by the end user is required. And this is different per bank. I can't imagine why Fintechs want this and how this is going to differentiate them from the banks.
The (final draft) RTS states that the APIs of the banks need to match the functionality and service levels that the banks offer to the end user via their own channels. With this the APIs should at least give Fintechs the same level of access as screen scraping does. This makes me wonder why Fintechs believe that they are better of with screen scraping than with APIs.
The question may be raised what authority will be assigned to take what measures if a bank does not meet that RTS rule. Possibly this is defined in the transition of PSD2 into the local jurisdiction of the concerning countries. The discussion could be closed if everything was not left that much in the open, but the APIs that banks must implement are clearly specified, as is the case with a comparable initiative in India, UPI.
30 May 2017 17:00 Read comment
the complaint is here that Apple shields off the NFC device on the iPhone to be connected to no other apps than their own wallet. The fact that banks did not launch an alternative NFC app/wallet for the iPhone was not they did not wanted to, but that it was/is technically impossible without Apple opening access to the NFC device.
14 Feb 2017 10:12 Read comment
Hi Sunil,
Fully agree with your PoV. If the burden is too high for the end user (and everything that takes more than one click will be) it will impact e/m-commerce conversion rates and/or fall back to less secure (but easier to use) payment instruments.
I also believe that HCE/SE in combination with TEE can play a role in this. This makes it possible to have an authorisation message digitally signed with keys securely stored in the cloud/SE (as happens with a NFC driven card transaction). TEE is used to make sure that only trusted Apps can access the relevant APIs. This mechanism can not only applied for securing payments, but also secure signon and signing of documents.
07 Feb 2017 13:21 Read comment
Good article. Another key benefit that can be mentioned is reduction (elimination) of market risk. No bi-lateral inter-bank exposures anymore which makes the market much less vulnarable for situations like we had in 2008.
What to think about settlement of international payments via a CLS Bank managed DLT (funds covered via deposits with linked central banks) instead of bi-lateral nostro/vostro accounts.
04 Jan 2017 10:17 Read comment
With PSD2 coming up (in Europe) and that banks in other parts of the world are voluntarily starting to make customer account accessible via APIs for non-banks (Morgan Chase with Wallmart and Shell in US, several Chinese banks with WeChat Payments), there is no need for Apple to become a bank in order to provide the customer a seamless and instant payment service to the end user and merchants. I agree this development will create a major threat for the traditional card brands.
14 Jun 2016 09:23 Read comment
Impressive piece of envisioning and innovation that is displayed here by Ford.
23 Feb 2016 11:58 Read comment
Richard DearBusiness Development Director at Icon Solutions
Pavan HaldiaLead Business Analyst at Icon Solutions
Darren CapehornDirector of Services at Icon Solutions
Adam RichardsonHead of Payments Architecture at Icon Solutions
Welcome to Finextra. We use cookies to help us to deliver our services. You may change your preferences at our Cookie Centre.
Please read our Privacy Policy.