How PSD2 is set to change banking up as we know it …

Fig. 1 – A prophetic vision by Bill Gates!? – Taken from: https://www.slideshare.net/patrickpijl/how-square-is-disrupting-banks/6-Bill_GatesBANKING_ISNECESSARYBANKS_ARENOT

“Banking is necessary.  Banks are not.”  Yep. Bill Gates said it. Back in 1994. And 28 years later, it’s it’s set to become reality. From the 1st January 2018, banking will no longer be the exclusive domain of banking institutions because PSD2 is going to drastically alter the way in which we bank.

The biggest consequence is that more than 4,000 European banks will need to open their legacy (mainframe) data stores to Third Party Players (‘TPPs’) and allow them to retrieve account information (‘AIS’) or initiate payments (‘PIS’). Both capabilities will be facilitated through APIs. I wrote about the scope and ramifications of PSD2 a few months ago, and I’ve been thinking ever since about the implications for existing banks and whether they’ve got reason to be scared.

It would be surprising if some of the traditional banks weren’t nervous about the extent to which they’ll have to open their kimonos under PSD2. And even if the Facebooks, Googles or Amazons of this world don’t become banks overnight, I expect the traditional, lifelong bank-customer relationship to slowly evaporate as a result of PSD2 (and subsequent versions of PSD).

Fig. 2 – PwC: PSD2 providing third party access to data and payments via APIs – Taken from: https://www.finextra.com/finextra-downloads/newsdocs/catalyst-or-threat.pdf

Facebook could easily decide to become an AISP (Account Information Service Provider – see Fig. 2 above), which would enable them to offer an aggregated view of a user’s bank accounts. As a result, they would be able to analyse spending behaviour, understand their users’ financial profiles and personalise a user’s banking experience. This isn’t that revolutionary, as virtual assistants like Cleo and Treefin have already starting offering this functionality, and I believe it’s highly likely that we’ll see it roll out across Facebook Messenger or WeChat in the near future. If you need more convincing, Facebook made their first move two years ago by appointing David Marcus, former CEO of PayPal, to head up Facebook Messenger, so watch this space. Similarly, US bank Capital One integrated with Amazon’s virtual assistant Alexa last year. This integration enables Capital One customers to pay their credit card bills and check their balances, by talking to their Alexa devices.

Fig. 3 – PwC: Six API-powered banking business models – Taken from: https://www.finextra.com/finextra-downloads/newsdocs/catalyst-or-threat.pdf

In addition, any remaining doubters about the power of APIs are likely to be converted as a result of PSD2. In the current Fintech landscape, there already are large number of banks that are either using APIs to hook into existing banking infrastructures (e.g. Varo Money) or offer additional services (e.g. N26). PwC recently conducted a study into the strategic implications of PSD2 for European banks and they listed no less than six API-powered banking business models (see Fig. 3 above).

Main learning point: It will be interesting to see what the actual impact of PSD2 will be, but if I were a traditional European bank, I’d be working as hard as I could to open up my APIs from today and start working on the creation of strong alliances with 3rd parties and their developers. As Nas once rapped on “N.Y. State Of Mind”, “I never sleep cause sleep is the cousin of the death.” If I were a traditional bank I’d follow Nas’ advice and give up on sleep completely …

Nas, lyric on “N.Y. State of Mind (Illmatic, 1994) – Taken from: https://uk.pinterest.com/MrConceptz/hiphop-101/

 

Related links for further learning:

  1. https://www.finextra.com/blogposting/14101/psd2-is-fast-approaching-dont-bury-your-head-in-the-sand
  2. https://www.finextra.com/videoarticle/1469/data-is-a-key-legal-issue-for-open-banking
  3. https://techcrunch.com/2017/01/12/what-facebooks-european-payment-license-could-mean-for-banks/
  4. http://www.ibtimes.co.uk/apple-facebook-amazon-primed-psd2-demolition-card-networks-1606188
  5. https://www.siliconrepublic.com/enterprise/fintech-banking-psd2
  6. http://www.bankingtech.com/675841/psd2-and-the-future-of-payments/
  7. https://www.evry.com/en/news/articles/psd2-the-directive-that-will-change-banking-as-we-know-it/
  8. http://www.sepaforcorporates.com/single-euro-payments-area/5-things-need-know-psd2-payment-services-directive/
  9. https://techcrunch.com/2015/07/12/the-future-of-finance-is-in-real-time/
  10. https://www.finextra.com/finextra-downloads/newsdocs/catalyst-or-threat.pdf
  11. http://www.pymnts.com/news/b2b-payments/2015/task-force-launches-eu-instant-payment-plan/.VYpo1rnhBTI
  12. https://venturebeat.com/2016/06/05/say-hello-to-messenger-banking/
  13. https://www.finextra.com/newsarticle/28602/capital-one-integrates-with-amazon-alexa-for-voice-powered-payments

 

App review: Grip

 

Grip is a London based startup that specialises in “smart event networking software”. That sounds like a relevant problem to solve, because don’t we all have a (secret) love-hate relationship with ‘networking’ at events!?

Yes, I’d love to meet with interesting people at events but I hate approaching people randomly.

Let’s have a closer look at how Grip is looking to solve this problem:

My quick summary of Grip (before using it) – I expect an app that uses clever algorithms to suggest relevant people to meet during events.

How does Grip explain itself in the first minute? – The Grip homepage describes the tedium involved in networking at events, with attendees often failing to make the connections they’d hoped for. Grip’s value proposition is to remove this tedium by unlocking “valuable connections at your event, saving attendees time and hard work. We use advanced algorithms to recommend the right people and present them in an easy swiping interface that your attendees will love.”

Getting started, what’s the process like? – Grip uses natural language processing to connect event attendees based on interest, needs and other things they’ve got in common. I liked Grip’s ability to tell an attendee not just who, but also why they should meet someone, in the form of Reasons To Meet.

Grip users will be able to tailor the real-time recommendations they get by setting their own matchmaking rules. I like the element of Grip not totally relying on machine learning, but also giving users the opportunity to feed their preferences into category rules into the Grip dashboard. This will influence the matchmaking engine in real-time and improve the future recommendations for event exhibitors, delegates and sponsors.

I can imagine that the data around users’ acceptance or rejection of Grip’s suggested matches, will help in further refining the app’s recommendations. This reminded me about the review that I did of THEO recently. THEO acts a ‘robo-advisor’ and uses machine learning to provide its users tailored investment advice.

Integrating the Grip API – Apart from the app, Grip have also got their own API, which makes it easier for companies to incorporate event matchmaking capability into their website or apps.

Main learning point: Grip is taking a significant problem for event attendees and exhibitors, and is using machine learning to solve this problem in a real-time and personalised fashion.

Related links for further learning:

  1. https://grip.events/handsake-event-networking/
  2. https://www.eventbrite.co.uk/blog/event-tech-adoption-at-events-ds00/
  3. https://grip.events/ai-event-matchmaking/
  4. https://grip.events/7-secrets-game-changing-event-networking/
  5. http://event-profs.com/world-first-artificially-intelligent-event-technology/
  6. https://marcabraham.com/2017/04/19/app-review-theo/
  7. https://www.eventbrite.co.uk/blog/event-tech-startups-2017-ds00/

 

Learning more about what’s coming under PSD2

The second instalment of Payment Services Directory, “PSD2”, will come into effect on 13th January ’17. By that date, EU member states are expected to have implemented the new payment rules as outlined in PSD2.

I recently listened to a radio programme where ex Barclays boss Antony Jenkins described PSD2 as “an opportunity for third parties to access a person’s bank data and to do something with that data.” He thus captured the core what PSD2 is all about: opening up banking data and using that data to create better, more integrated customer experiences.

Jenkins also talked about how in the new PSD2 world banks effectively provide the utility components that other services build on, acting as the frond end and being more customers experience focused. One can already see from the success of Fintech startups such as Monzo, Remitsy, Varo Money and Abra the distinction between financial service players that focus more on front-end customer experience and those concentrating on the underlying ‘plumbing’. Jenkins mentioned the concept “a browser for your financial life”. Viewed within the context of PSD2, the idea of a central browser for one’s financial life really resonated with me.

All of this made me have a first stab at understanding the essence and ramifications of PSD2. This is what I’ve learned sofar:

Develop new payment solutions – Account Information Service

Ultimately, PSD2 aims to stimulate new payment solutions, using digital tools and infrastructure to create a more seamless payment experience. As a result of PSD2, there will be two new types of service providers: “account information service” (‘AIS’) and “payment initiation service” (‘PIS’).

Under PSD2, an AIS is defined as an “an online service to provide consolidated information on one or more payment accounts held by the payment service user with either another payment service provider or with more than one payment service provider”. As customers, we can benefit from AIS through its ability to offer an aggregated view of a customer’s accounts. Having this consolidated view should make it easier for customers to analyse their transactions and spending patterns across a number of their payment service providers (‘PSPs’).

Develop new payment solutions – Payment Initiation Service

Whereas AIS covers the aggregation of account data, a payment initiation service (‘PIS’) enables the movement of money between accounts with different PSPs. Under PSD2, a PIS is “a service to initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider.”

In essence, a PIS acts as an online service which accesses a customer’s payment account to initiate the transfer of funds on the customers’s behalf, provided the customer has consented and authentication has taken place (see Fig. 1 – 2 below). Payment initiation services thus provide an alternative to paying online using a credit card or debit card. PIS aren’t allowed to hold payer funds or store sensitive payment data but can initiate payment transactions on behalf of customers.

To me, the future payment initiation capability for “merchants” feels like the most exciting opportunity that PSD2 offers. It means that merchants such as ecommerce marketplaces can access the payment accounts on their customers’ behalf and initiate payments, without the need for credit or debit cards. PIS will be allowed to communicate securely with the customer’s bank and seek information required for payment initiation.The PIS will use APIs to link to the merchant’s website or app with the customer’s bank.

Fig. 1 – PIS workflow, merchant acting as a Payment Initiation Service Provider (‘PISP’)  – Taken from: https://www.temenos.com/globalassets/mi/wp/16/temenos_psd2_whitepaper_v2.pdf

Fig. 2 – PIS workflow, merchant goes through a PISP to collect money from a customer’s bank account – Taken from: https://www.temenos.com/globalassets/mi/wp/16/temenos_psd2_whitepaper_v2.pdf

Reinforced customer protection

As a direct consequence of the data sharing and integrations that PSD2 enables, customer protection will be increased. For example, all payment service providers will need to prove that they have put specific security measures in place to ensure safe and secure payments. PSD2 requires “Strong Customer Authentication” (‘SCA’), which is also known as two-factor authentication. Two-factor authentication is already a common feature of lots of digital products and services (see the Google example in Fig. 3 below). Typical components of two-factor authentication are (1) knowledge (something you know, such as a password) and (2) possession (something you have, such as a card or mobile device) or ‘inherence’ (something you are, such as a fingerprint or voice recognition). Each element must be independent from the others so that if one is breached this does not compromise the integrity of another.

Fig. 3 – Google 2-factor authentication example – Taken from: https://paul.reviews/does-two-factor-authentication-actually-weaken-security/

Main learning point: My biggest, initial takeaway from learning about PSD2 is that digital payment services will become a lot more seamless and easy. APIs will act as key ‘enablers’ of new opportunities to integrate customer’s financial activities and online behaviours.

Related links for further learning:

  1. https://www.linkedin.com/pulse/banking-apis-what-you-think-jason-bates
  2. http://www.eba.europa.eu/-/eba-paves-the-way-for-open-and-secure-electronic-payments-for-consumers-under-the-psd2
  3. http://www.iosco.org/library/pubdocs/pdf/IOSCOPD554.pdf
  4. https://www.finextra.com/blogposting/12668/psd2—what-changes
  5. http://www.pwc.com/it/en/industries/banking/psd2.html
  6. https://www.fca.org.uk/firms/revised-payment-services-directive-psd2/ais-pis
  7. https://www.temenos.com/globalassets/mi/wp/16/temenos_psd2_whitepaper_v2.pdf
  8. https://www.starlingbank.com/explaining-psd2-without-tlas-tough/
  9. https://www.fca.org.uk/firms/revised-payment-services-directive-psd2/consumer-protection
  10. http://www.bbc.co.uk/programmes/b08hpwbz
  11. https://www.gmc.net/blog/banks-beware-impact-psd2-and-xs2a-accelerating-digital-disruption

Seamless payments – Learning more about Dwolla and their API platform

I recently heard Shamir Karkal, Head of Open APIs at BBVA, talking about open platforms and I was intrigued. In the podcast episode Shamir talked about the power of APIs, but at the same time stressed the importance of having a strong platform that these API end points can hook into.

Shamir talked about building a product with a platform attached. Instead of just building a set of APIs, we should treat APIs as a way in for customers, developers and third parties to hook into the capabilities of our business. For example, hooking into all the things that banks typically tend to do well: compliance, risk management and customer support.

My ears really perked up as soon as Shamir started talking about Dwolla. Dwolla is US based peer-to-peer payments company, whose mission it is to facilitate “Simple payments. No transaction fees.” Dwolla is powered by APIs, making it easy for US users to link their Dwolla account to a US bank account or credit union account to move money. Setting up a Dwolla account is free, and there’s no per transaction fee. Users can collect payment on an invoice, send a one-time or recurring payment, or payout a large number of people at once. Dwolla also offers this a white label solution (see Fig. 1 below).

dwolla-white-label-api

Fig. 1 – Dwolla’s white label version of their API – Taken from: http://apievangelist.com/2015/09/03/dwolla-just-released-a-white-label-version-of-their-api-are-you-ready-for-the-wholesale-api-economy/

In essence, what Dwolla does is enabling real-time payments between Dwolla accounts and another bank account that users want to send money to. Dwolla are integrated with banks such as BBVA, having Dwolla APIs ‘talk’ to the bank’s APIs. Dwolla has created some form of a protocol in the form of FiSync which aims to make it more secure for users to transmit information between accounts. FiSync enables the use of secure authentication and tokenisation in the comms between Dwolla and accounts like those of BBVA Compass. This way, BBVA Compass account holders don’t have to share their account info with Dwolla (see Fig, 2 below).

screen-shot-2016-09-27-at-20-35-26

Fig. 2 – Workflow of a connecting a FiSync-enabled bank account to Dwolla – Taken from: https://www.dwolla.com/updates/breaking-down-real-time-secure-authentication/

Main learning point: I love how Dwolla’s proposition is almost entirely API based, making it easy for its users to transfer money to bank accounts and credit union accounts. Dwolla definitely feels more seamless, secure and cost-efficient compared to the way in which users traditionally transfer money from one account to another.

Related links for further learning:

  1. http://11fs.co.uk/podcasts/ep111-interviewed-innovators-really-changing-banking/
  2. https://www.bbva.com/en/news/disciplines/shamir-karkal-building-financial-future-bbvas-platform/
  3. http://finovate.com/open-api-shamir-karkal-to-head-bbvas-new-developer-platform/
  4. http://apievangelist.com/2015/09/03/dwolla-just-released-a-white-label-version-of-their-api-are-you-ready-for-the-wholesale-api-economy/
  5. http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com.ibm.dp.doc/oauth_threeleggedflow.html
  6. https://www.dwolla.com/updates/breaking-down-real-time-secure-authentication/
  7. http://help.dwolla.com/customer/portal/articles/1940212-bbva-compass-dwolla-faq?b_id=5440
  8. https://www.bbvacompass.com/compass/dwolla/

Ben Essen and The Quantified Self

The other day I heard a few people use the term “quantified self”. Through Wikipedia I learned that the quantified self stands for “a movement to incorporate technology into data acquisition on aspects of a person’s daily life in terms of inputs, states, and performance.” In other words, this is all about quantifying peoples’ lives and behaviours, thus being able to learn more about people and their different activities and needs.

Ben Essen, a London-based Creative Strategy Director, recently talked about the quantified self at this year’s SXSW in Austin. His talk was titled “Know Thyself. Self Actualization By Numbers” and these are the main things that I learnt from Ben’s presentation:

  1. Essen’s Hierarchy of Quantified Self – Similar to Maslow’s Hierarchy of Needs, Ben Essen has come up with his own “Essen’s Hierarchy of Quantified Self” (see Fig. 1 below). Ben’s hierarchy starts with “goal-progress” (e.g setting daily goals with apps such as Fitbit and Wello) and ends with the “Quantified Society” where everything is informed by our personal data. I like how Ben’s ‘pyramid’ moves from “insight” to “enhancement”, thus highlighting the changing role of personal data as one moves up along the hierarchy.
  2. Context-driven measurementMelon is a great example with regard to quantifying personal data within a specific context. For instance, with Melon you can track how focused you are when you’re working on your laptop compared to when you’re meditating (see Fig. 2 below). Ben refers to this as “lifestyle context”, which implies that your personal data are likely to vary dependent on your mood or the activity that you are doing. Another good example is Nest which home products are designed to learn from user behaviour. I’ve written a few posts on wearable devices and wearable trends to look out for.
  3. “The Human API” – Ben ultimately envisages a ‘Human API’ which encapsulates all your personal data, irrespective of the underlying data source (e.g. email, browse history, search, etc. – see Fig. 3 below). I’ve been trying to visualise an API of all my personal data (e.g. “went to a Danny Brown gig last month, purchased “The Mindful Leadership” on his Kindle and checked in with his Oyster in north London this morning”) and how a brand or other 3rd party would tap into this data set. This concept provides both opportunities (e.g. fully personalised experiences) as well as risks (e.g what happens if my Human API falls into the wrong hands?).
  4. Connecting data sets and devices – I strongly believe that the next frontier in digital development is the connection of different devices and the connection of a user’s various data sets. The possibilities are endless, but I reckon it will take a while to properly connect personal devices and data, thus creating a ‘personal platform API’ similar to the “Human API”, as mentioned by Ben in his talk at SXSW.
  5. Data shouldn’t replace our intuition – I personally prefer using the term “data informed” over the more common “data driven” since I feel that there are some strong limitations to a purely data-driven approach (I’ve blogged about these constraints previously). In his talk, Ben stressed the importance of understanding and interpreting personal data and using data as a source for decision making. However, Ben was keen to stress that “self-tracking must feed our intuition. Not replace it.”

Main learning point: Ben Essen has got a lot of interesting and thought-provoking insights around the topic of the “quantified self”. We are moving steadily in the direction of a society where a lot our behaviours, mood states and activities can or have already been quantified. The idea of a quantified self and a “Human API” will in my opinion truly materialise once we all get smarter about how we connect different devices and data sets. In the meantime, I suggest looking into some of Ben’s observations and reservations around self-tracking and have a think about about how we can move up “Essen’s Hierarchy of Quantified Self”.

Fig. 1 – Essen’s Hierarchy of Quantified Self (taken from: http://www.slideshare.net/benessen/knowthyself-sxsw-benessen) Essen's hierarchy if qs Fig. 2 – Melon Kickstarter video (taken from: https://www.kickstarter.com/projects/806146824/melon-a-headband-and-mobile-app-to-measure-your-fo)

Fig. 3 – The Human Api by Ben Essen (taken from: http://www.slideshare.net/benessen/knowthyself-sxsw-benessen) The Human API

Related links for further learning:

  1. http://www.slideshare.net/benessen/knowthyself-sxsw-benessen
  2. http://www.wired.com/insights/2013/11/the-human-api-dont-forget-the-people-for-the-program/
  3. http://gigaom.com/2013/06/17/startup-human-api-wants-to-bring-quantified-self-data-into-the-mainstream/
  4. http://blog.programmableweb.com/2013/07/02/the-quantified-self-growing-interest-in-apis-to-manage-personal-data/
  5. http://quantifiedself.com/2011/09/robin-barooah-i-am-broken-or-i-can-learn/
  6. http://www.computerweekly.com/news/2240212466/Google-bets-on-internet-of-things-with-Nest-acquistion
  7. http://quantifiedself.com/2012/12/get-your-mood-on-part-1/
  8. http://www.digitalmcgyver.com/personal/gadgets/moves-app-great-for-life-logging-worthless-for-quantified-self/
  9. http://www.slideshare.net/mark_pdx/mark-leavitt-using-data-to-hack-my-habits-and-whip-up-my-willpower-show-and-tell-for-qs-europe-may-2013

In-car platforms are growing, with Ford and GM opening up to developers

A while ago I wrote about Cadillac and its car infotainment system. Long hailed as one of the key digital trends for the next few years to come, it looks like in-car platforms are going to fulfil their promise this year. There are a few recent developments which clearly point into this direction:

  1. Launch of the Ford Developer ProgramEarlier this week, Ford launched its developer program which allows app developers to connect their Android and iPhone apps to Ford’s SYNC voice-activated interface. Ford’s SYNC application is essentially about drivers or passengers using voice commands to interact with their vehicle.
  2. Safety first! Even though Ford is opening up its ‘platform’, it will nevertheless apply a strict review process of incoming app submissions. Safety of the driver and passengers still remains Fords core focus. Safety is in fact one of the key reasons why Ford encourages developers to use its SYNC technology in the first place: “Our focus is to enhance the driving experience by minimizing the distractions caused by hand-held usage of smartphones while driving,” explained Julius Marchwicki, global product manager for Ford SYNC AppLink. “We know consumers are using apps such as music and navigation while driving; therefore, by making AppLink available to developers, we can help ensure relevant apps can now be voice-controlled.”
  3. Vehicle data – Whereas the current focus of most existing car apps is on entertainment, the next big development will be around vehicle data such as fuel efficiency and ride sharing. In an interesting article, Liz Gannes from tech site AllthingsD, points out that “carmakers opening up vehicle data to developers will be the next big step.” General Motors (‘GM’) is a good example in this respect. It shares “in-vehicle APIs” with developers through its website.
  4. More to come … – Like Ford, GM has opened up its API and is looking to build a library of apps. It is already integrating with popular entertainment apps. However, the main idea behind opening up its API through its developer site and providing developers with a Software Development Kit (‘SDK’) is to create car-specific apps, using vehicle data (see my previous point). The fact that both Ford and GM recently decided to open up their APIs and create developer programmes, indicates that there’s a lot more to come in this area, with other carmakers and technology companies likely to follow suit.

Main learning point: I believe that the full extension of digital experiences and connectivity into the car is going to be a big thing over the next year. It will be interesting to see the transition from purely entertainment oriented apps to ‘smart’ car-specific apps which will tell you about things like your driving behaviour and fuel usage. Even though the likes Google have started experimenting with cars that drive themselves, that’s future music. Instead, having external developers help car giants make better use of vehicle data is likely to be the next big thing.  

ford-developer-sm

Related links for further learning:

http://allthingsd.com/20130107/automakers-open-their-in-car-platforms-first-up-ford-and-soon-gm/

http://www.fiercemobilecontent.com/story/ford-developer-program-registrations-top-1000-first-week/2013-01-11

http://www.theinquirer.net/inquirer/news/2234501/ces-ford-announces-developer-program-for-sync-applink

http://ces.cnet.com/8301-34438_1-57563405/ford-gm-open-up-to-developers-at-ces-2013/

http://ces.cnet.com/8301-34438_1-57562553/gm-opening-cars-up-for-app-development/

http://www.pcworld.com/article/2024572/the-open-source-car-automakers-eagerly-woo-app-developers.html

http://www.engadget.com/2013/01/08/qnx-concept-bentley-continental-gt/

Rdio partners with Echo Nest and shows it’s serious about things

Last March I learned about Rdio opening up its API and launching an affiliate programme. In a move to strengthen its proposition, Rdio has now announced a partnership with music analytics and recommendation service Echo Nest. The partnership will allow developers to add music recommendations from Echo Nest to their apps and then actually play the music using streams from Rdio.

The Echo Nest is a music intelligence service which develops bespoke applications for customers like the BBC and MTV but also for independent app developers. It provides a platform that analyses music in various ways (e.g. similar artists or songs, beats or loudness).

MusicMaze is a good example of an app where the respective APIs from Rdio and Echo Nest have been combined pretty well; this webapp maps relationships between musicians (data powered by Echo Nest) as well as enables users to listen to related music (streaming powered by Rdio). Non-subscribers to Rdio will hear 30 second previews and Rdio subscribers will be able to listen to the full songs.

Main learning point: Rdio is clearly serious about making the most of its API and strengthening its affiliate subscription programme. Their latest partnership with Echo Nest seems very logical in this respect; it adds extra analytics capability to its offering, which may very well be of interest to the developer community. Time will tell I guess.

Related links for further learning:

http://blog.rdio.com/post/5161479190/announcing-rdios-partnership-with-the-echo-nest

http://www.readwriteweb.com/archives/music_nerds_gain_new_powers_with_rdio_echonest_api.php