Monday, 16 October 2017

Why took BBVA so long to launch an m-remittance solution?

BBVA has today announced the launch of Tuyyo an m-remittance solution for the US-Mexico remittance corridor that will try to tap a $2,000 million/month flow of money between the two countries.

Tuyyo gives recipients free, 24/7 access to 11,000 Bancomer ATMs, with no need for a bank account or ATM card, eliminating the hurdle of traveling long distances or wating in lines to pick up money. Tuyyo users can expect to access their money within minutes of it being sent.

BBVA is not a newcomer to the digital remittances sector. It operates BBVA Transfer Services (BTS), which has facilitated money transfer services to Mexico since 1995. However, it has not been until today that BBVA has launched an m-remittace service that leverage their foothold in the US and Mexico and that will compete with Xoom (created in 2001 and acquired by Paypal in 2015 in a $1.09 billion deal) and the likes.

Back in 2013 I wrote an article in Visible Banking: m-remittances: the new el Dorado for mobile transfers? There, I pointed out the business opportunity for m-remittances and how the combination of high cost of sending money and new mobile solutions placed the industry in the list of industries to be transformed. I also added:

"I wouldn´t be surprised if BBVA any time soon connected BBVA Compass mobile app with BBVA Bancomer Dinero Móvil service to seize more of the almost $2 billion in remittances that every month Mexico receives in electronics transfers."

m-remittances: the new el Dorado for mobile transfers?

If the business opportunity was so clear (at least to me), why took BBVA so long to launch an m-remittance solution?

Thursday, 3 August 2017

Mercedes Pay llega a España

Así se desprende de la información proporcionada por el Banco de España, en el que Mercedes pay, S.A., empresa de dinero electrónico autorizada en Luxemburgo, ha sido registrada por el Banco de España como entidad de dinero electrónico para operar en nuestro país.

Este movimiento llega pocos meses después de que Daimler comprara PayCash Europe, una entidad de dinero electrónico con sede en Luxemburgo. Según anunció Daimler, con esta adquisición se formaría Mercedes Pay, el proveedor de servicios de pago para todas las soluciones de movilidad del grupo Daimler. Entre dichas soluciones, Mercedes Pay permitirá que los cliente registren su datos de pago una sola vez y pueda ser reutilizada en todos los servicios de movilidad del grupo automovilístico.

‘Mercedes pay' allows our customers to easily and securely pay for our mobility offerings and services using their smartphones. “Mercedes pay” will mainly benefit customers who, in the future, will only need to provide their payment details one time, in order to be able to use a range of Daimler’s services. This is made possible by the eWallet function, a virtual source of payment.”

Mercedes Pay es una subsidiaria de Daimler Mobility Services GmbH y está integrada en Daimler Financial Services, la unidad que aglutina los servicios de financiación y movilidad de Daimler. Esta unidad gana más de 1.000 millones de euros al año y tiene un ROE de casi el 19%. De hecho, es la unidad más rentable de todo el grupo Daimler.

Esperamos ver pronto cómo Mercedes Pay mejora la experiencia de Car2Go y mytaxi, que ya tienen 2,6 millones y 8,2 millones de usuarios respectivamente. Una gran base sobre la que crear nuevas experiencias, desde pago en un click en cualquier servicio de Daimler hasta loyalty para los usuarios recurrentes de sus servicios de movilidad.

Thursday, 27 July 2017

PayPal recipe for a successful transformation in Payments

PayPal reported yesterday 2Q17 results that demonstrates its solid position in the Payments industry. In the press release Dan Schulman, President and CEO of PayPal describes Paypal´s recipe for success:

“Our strong results reflect PayPal’s transformation from a single product to a platform company, from a vendor to a strategic partner to both merchants and ecosystem players, and from a checkout option to an increasingly more central way for consumers to manage and move their money.”

PayPal Reports Second Quarter 2017 Results and Raises Financial Guidance for Full Year

In my view one of the highlights of that recipe is the strategic partnerships. Since early 2016, PayPal has announced 22 partnerships agreements with card schemes, major US issuers, global tech companies, and select international players. This is really transformative, as PayPal is being now recognized as partners by certain players previously thought of as competitive threats.

Recent metrics suggest that this new direction is paying off:

  • TPV Growth: 26% y/y
  • Net Revenue Growth: 20% y/y
  • Active Account Growth: 12% y/y (or +6.5mn to 203mn)
  • Transaction Growth: 23% y/y
  • Mobile Payment Volume Growth: 50% y/y to 34% of TPV (vs 32% in 1Q17).

Friday, 21 July 2017

HR Treasury response to PSD2 public consultation dispels some doubts

It is six months until the PSD2 comes into affect, and there are many questions not answered yet about its applicability. This week, the HM Treasury has published its response to the consultation document published in Ferbruary 2017. This response dispels some doubts some players still have on what banks have to deliver from 13 January 2017, the role of screen scrapping and APIS during the transitory period or the access to credit cards for initiation of payments.

The documents lists the 85 respondents in which you interestingly will find Apple.

Below a summary of the main points related to AIS/PIS:
  • The government can confirm that, from 13 January 2018, ASPSPs will have to allow access to payment accounts for all registered or authorised TPPs, unless they have an objective reason (such as fraud) to deny access. The FCA sets out further detail on blocking TPPs for fraud in their draft Approach Document. ASPSPs will not have to provide access to unregulated or unauthorised TPPs.
  • ·         Prior to the RTS coming into effect, registered or authorised TPPs will be able to access consumers’ accounts directly by utilising their login details (commonly known as ‘screen-scraping’), or via Application Programming Interfaces (APIs) such as those designed to the Open Banking Standard. This is in line with the PSDII, which states that all registered or authorised TPPs must be able to access accounts.
  • ·         The government’s expectation is that the Open Banking directory and standard APIs will start to be available to TPPs for the majority of UK consumers’ current accounts from 13 January 2018. The government is of the view that this access route offers a more secure and stable interface for ASPSPs, while also creating a more competitive ecosystem for TPPs by lowering the barriers to entry. The government therefore strongly encourages TPPs to use these APIs where they are available, other ASPSPs to use the Open Banking standard APIs for their payment accounts, and the Open Banking Implementation Entity to broaden the scope of Open Banking to the full PSDII product suite in due course.
  • ·         ASPSPs will only be expected to provide equivalent access to that available online to customers. Therefore if consumers cannot initiate a payment from their online credit card account, PISPs cannot initiate a payment either (and therefore have no right of access). Equally if there is no online account available (as is the case for many gift cards) there is no requirement for access to be provided.
  • ·         The government maintains its view that direct debits are out of scope of payment initiation services unless this facility already exists within a user’s online payment account. The PSDII definition of payment initiation also does not extend to cancelling or amending existing direct debits or standing orders.
  • ·         Regarding specific access routes for AIS/PIS services, the government:

o   is aware that the Commission is examining the question of whether certain corporate systems, such as those operated by SWIFT and host-to-host services, should be exempt from the scope of the AIS & PIS regimes
o   does not intend to explicitly carve TPMs out of the definition of AIS/PIS services, as they could be used as an access route for TPPs providing services which should be in scope.
  • ·         Regarding which TPP needs to be authorised if there is more than one, the general rule is that the TPP which the customer has a contractual relationship with for accessing their account is the TPP which needs to be registered or authorized.
  • ·         The government recognises the concerns of ASPSPs who are seeking compensation from a PISP (where the PISP is liable) and can confirm that ASPSPs will have a right of action against PISPs in the event they breach their regulatory obligation to refund an ASPSP for an unauthorised transaction. However, we would also encourage industry to develop a voluntary solution to better address this issue for all parties involved.

Wednesday, 12 July 2017

The Hard Truth About Business Model Innovation

Business Model Innovation is one of my favourite topics. I read this article a few months ago, and re-read that again this week; I think that as any other Clayton Christensen´s article is worth reading. My favourite quote of the article is:

"Over the long term, the greatest innovation risk a company can take is to decide not to create new businesses that decouple the company´s future from that of its current business units".

The Hard Truth About Business Model Innovation

This made me think about the latest innovation attempts by banks. Specially, the creation of new units, normaly under the name of New Digital Business, where they try to innovate and generate new businesses. However, I always had the impression that business model innovation wasn´t really a priority for these new created units, and that their efforts weren´t really aimed at decoupling the company´s future from that of its current business units. Well, apparently, until now:

"Diana Biggs has been appointed as Head of Business Model Innovations for UK & Europe. Biggs will oversee all business model innovation projects, including managing the ‘test and learn’ proposition opportunities related to open banking and PSD2".

HSBC Makes Key Hire To Augment Digital Innovation Team 

Wednesday, 10 May 2017

¿Neobanco, Virtual Bank? No, Fintech

En los últimos días he tenido la ocasión de asistir a un par de eventos organizados por Finnovista: el Fast Track Madrid de Startbootcamp Fintech en Mexico City donde participé como mentor, así como el Pitch Day Madrid de Mayo. Ambas grandes oportunidades para tomar el pulso de la industria fintech española.

En ellas pudimos ver presentaciones entre otras de BNext, así como  de Fintonic. La primera, una prometedora fintech en fase beta y la segunda una de las fintechs más consolidadas del panorama fintech español con mas 400.000 usuarios activos.

Lo que me llamó la atención es como ambas se definen: Fintonic ya no se define como un PFM, sino como un Virtual Bank, y BNext se definió inicialmente como un neobanco pero a lo largo del pitch también se definió como marketplace bank, challenger bank y también virtual bank. Esto demuestra, en mi opinión, que aún no hemos encontrado un término que defina a los nuevos proveedores no bancarios de servicios financieros.

Es cierto que ya casi todos aceptamos que los productos financieros ya no tienen por qué ser creados y distribuidos por bancos:

“Banking is necessary, banks are not”
Bill Gates

“Banking is no longer somewhere you go, it´s something you do”
Brett King

El problema surge cuando queremos dar nombre a aquellos jugadores que no siendo bancos están haciendo “banking”, ya que no encontramos un único término (neobank, challenger bank, virtual bank, etc.).

Mi propuesta para aclarar esta situación pasa por definir qué no son y para ello propongo partir de la definición de un banco. ¿Qué es, pues, un banco?

“Un banco es una empresa que tiene por objeto la captación de dinero del público para invertir por cuenta propia en operaciones de crédito, añadiendo a esta función canalizadora, la asunción del riesgo de insolvencia de los prestatarios y riesgo de liquidez que se origina al transformar los plazos”
Banco de España

Por tanto, sabemos que ni BNext ni Fintonic son un banco, ya sea neo, digital o virtual. No lo son. ¿Qué son? Bueno, de momento lo que sabemos es que son fintechs y probablemente en unos meses sean también AISP (Account information Services Providers) regulados bajo la PSD2.

Thursday, 23 March 2017

Main highlights of the HM Treasury consultation paper on the implementation of PSD2

Objectives of the third party provider access rules

“The CMA included in its final remedies published on 9 August 2016 a requirement for nine banks across Great Britain and Northern Ireland, working with other ASPSPs and current and potential “third party” providers to deliver an Open Banking Application Programming Interface (API) Standard. The CMA make clear that this API Standard will need to align with the PSDII, requiring banks to deliver it by January 2018 when the PSDII comes into effect.”

“Within the PSDII context, the Open Banking API Standard is expected to provide the framework for how AISP and PISP software authenticates, accesses data, and initiates payments with an ASPSP.”

“The government therefore sees the PSDII implementing regulations as providing the legislative foundations on which the Open Banking API Standard then sits. Although APIs are only one method by which ASPSPs could provide the access to AISPs or PISPs mandated under the PSDII, the government believes a commonly utilised API framework will lead to greater competition in the retail banking and “third party” services market and better outcomes for payers and other end users.”


“Best practice is expected to involve customers authenticating themselves directly with their ASPSP, i.e. providing their payment account login details only to their ASPSP, rather than to the AISP or PISP, with confirmation of access then provided by the ASPSP back to the AISP or PISP. This mechanism will limit risk to payers and other end users and is expected to form a part of the Open Banking API Standard.”

“Subject to the EBA RTS, the government expects an AISP will be able to access the information contained within the payment account held by an ASPSP on both a one-off and ongoing basis. Ongoing basis means that users will be required to authenticate their identity once and then, with appropriate consent, the AISP will continue to be able to access their information even after the user’s immediate session has ceased. ASPSPs are expected to allow for regular communication sessions with the AISP, but not necessarily to provide an uninterrupted data stream.”

“Subject to the EBA RTS, the government expects the initiation of transactions through a PISP to require authentication each time a payment is initiated.”

Role of the competent authority

"In line with current authorisation arrangement for payment institutions, the government believes that the FCA should undertakes the role of registering and authorising AISPs and PISPs, and ensuring that ASPSPs, AISPs and PISPs are meeting their obligations under the legislation. As part of this, ASPSPs must notify the FCA where access is denied to AISPs or PISPs."


“The PSDII, and the proposed draft implementing regulations, are clear that where a payer is using an AIS or PIS, explicit consent must be obtained by the AISP or PISP for the service or payment transaction in question. The authorisation of a payment transaction does not have to be given by the user directly to the ASPSP but can be given only to the PISP.”


“The following types of accounts likely to fall within the definition of online payment accounts:

personal current accounts
business current accounts
credit card accounts
flexible savings accounts
e-money accounts”

“ASPSPs are expected to provide to an AISP access to the same information regarding a payment account as is available to the user when accessing their account online directly with the ASPSP. This could include:

account information, such as name on the account, address of the account holder, account number
product details, such as the product type, interest rate when in credit, overdraft amount, interest rate when overdrawn
transaction data to the same level of granularity and covering the same time periods as is available to the end user online”

“ASPSPs are expected to provide to a PISP access to the same functionality that is available to the user when accessing their payment account online directly with the ASPSP. For the majority of online payment accounts this is likely to include credit transfers and the establishment of standing orders, but not the establishment of direct debit mandates if this is not already available to the user online.”

“The government interprets the definition of AIS as meaning that an AISP uses some or all of the information from one or more payment accounts held by the PSU with one or more ASPSPs, to provide an information service. The government expects these services to include, though not be limited to:

dashboard services that show aggregated information across a number of payment accounts
price comparison and product identification services
income and expenditure analysis, including affordability and credit rating or credit worthiness assessments, and
expenditure analysis that alerts users to consequences of particular actions, such as breaching their overdraft limit”

Initial implementation

“The government’s implementing legislation will come into force on 13 January 2018, including the requirements around access set out in article 66 and 67. However, provisions related to security in articles 65, 66, 67 and 97 will not come into force until 18 months after the EBA RTS on SCA and secure communication are in force. As such, these provisions are not expected to be in force before autumn 2018.”

“During this initial period ASPSPs will be expected to provide access to AISPs and PISPs from January 2018 and, as industry will have had sight of the draft RTS, the government would expect this to be done in line with the draft RTS wherever possible.”

“During this period both ASPSPs and AISPs/PISPs will be undergoing a learning process and will be expected to work closely across industry, and where appropriate with the FCA, to overcome challenges that emerge and ensure that users have the ability to use AIS or PIS.”

Monday, 6 March 2017

Main highlights of the EBA final draft on the RTS on Strong Customer Authentication and Common and Secure Communication

Below the main highlights of the EBA final draft on the Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Communication published on February 23th, 2017.

1) Screen scrapping is no longer allowed

The EBA interprets the security requirements under PSD2 as meaning that the TPPs will no longer be able to screen scrape. The EBA understands screen scraping as a way for the PISP to access the customer’s online account by pretending to be that customer, often using advanced robot technology. The EBA disagrees with the suggestion of some of the respondents that not allowing screen scraping would be against the principle of non-discrimination. 

2) Cards on file is out of scope of PSD2

It is the EBA’s understanding that card-on-file solutions and their providers are not within the scope of PSD2 and therefore not within the scope of these RTS. Providers of card-on-file solutions are not PSPs in the sense of PSD2 unless of course the PSP conducts other activities that are within the scope of PSD2 and would therefore be regulated for that purpose.

3) Transactional risk-based exemption from SCA is now allowed (up to a maximum value of EUR 500)

The EBA agrees with the view expressed by the respondents that a risk-based approach, including the ability to conduct detailed TRA and fraud monitoring, is essential to achieve the objective under PSD2 of reducing overall fraud. Consequently, the EBA arrived at the view that, in accordance with Article 98(2)(a) PSD2, an exemption based on such an analysis should be added in a new Article 16 of the RTS. The RTS also reiterate the importance of risk and fraud monitoring in general as a necessary complement to the principle of SCA laid out in PSD2 as stated in a new Article 2 RTS

4) Merchants cannot apply transactional risk-base exemption from SCA

The EBA also explains in rationale 24 that its interpretation of PSD2 suggests that the transaction-risk analysis (TRA) exemption from SCA can be applied by the payee’s and payer’s PSPs, but not by the payer or the payee themselves. The liability rules also suggest that the payer’s PSP should have the last say on whether or not the TRA exemption is used for a specific transaction.

5) PSPs that want to apply TRA exemption from SCA will have to track fraud rates and being audited 

RTS now require PSPs to monitor all of their fraud rates as well as the performance of the TRA method used, which must additionally be independently assessed by qualified auditors. Furthermore, the PSP must report any change related to the use of this exemption to the national authorities



Wednesday, 1 March 2017

Bye, bye, tarjetas

Hace casi un año compartí con algunos miembros del comité de dirección de mi anterior empresa, un extracto de una publicación de Brett King (CEO y Fundador de Moven y uno de las voces en Fintech más escuchadas) titulado Bye, bye, credit cards. Al final de este post os he dejado el enlace al texto completo (en inglés) para que lo leáis. Merece la pena.

El objetivo de mi mensaje era hacerles reflexionar sobre los grandes desafíos a los que se enfrenta el negocio de tarjetas con la llegada del tiempo real y la apertura del acceso a las cuentas corrientes, lo que posibilita hacer y recibir pagos en ellas en tiempo real, haciendo innecesario el uso de una tarjeta.

Uno de los pronósticos de Brett King es que para 2022 no existirán en los bancos ni un Head of Cards ni una unidad de tarjetas. Personalmente, comparto lo que hay detrás de la reflexión de King, no habrá jefes ni áreas de Tarjetas, sino de Pagos.

Y creo que en el mercado empezamos a apreciar movimientos desde lo aparentemente estético: CaixaCards pasó a llamarse Caixa Payments el año pasado, a movimientos organizativos y de negocio importantes:

- Este mes Barclays ha anunciado que Barclaycard UK se integra completamente dentro de la estructura de Barclays UK (el banco retail del grupo Barclays en UK), dejando de ser una unidad independiente.

- También este mes, Barclaycard (a través de Barclaycard Payment Solutions) ha firmado un acuerdo con Vocalink para permitir que los comercios que actualmente utilizan su payment gateway, puedan integrar la nueva modalidad de pago Pay by Bank App. Lo que significa que una unidad históricamente de tarjetas, empieza a facilitar a sus comercios clientes el pago de cuenta a cuenta en tiempo real, lo que hace innecesario las tarjetas.

Y tú, ¿crees que en unos años dejarán de existir las unidades de tarjetas de los bancos?