Community

We can all agree that PSD2 Open API is not easy to integrate to old CBSs.  And, both speed and security must be maximized in the process. 

Each bank has its own way of integrating to the CBS and regulatory guidelines for integrating to the world....with the expectation of publishing their interface specifications.  The killer app will be the application of Stronger Customer Authentication in a realtime interface using Open APIs to perform SCT-Inst transaction originated by millions of devices that are not necessarily known to the bank by regulated providers also not known to the bank.  A new industry is developing around this effort.  In the meantime, banks will be cautious and PISPs will have limited success.  

To your point about the customers' interest in using Open Banking, the customer is not likely to know if he/she is using Open APIs or not.  

As for replacing the CBS, the product/functional silos of these systems are being re-written with each day that passes.  Incumbents are breaking apart their Universal Banking Systems in order to look like micro-services that can be license function-by-function while others are starting from the ground up building new banking systems with modern architecture, data structures, coding techniques, etc.   The cost to do either have reached an equlibrium where many challengers are attempting to build from scratch rather than implement a UBS from an incumbent.  Creating micro-service farms that can rationalize the functions and interdependencies of existing UBSs is the challenge. Time will tell if it is even possible, much less, can they deliver the features in a distributed fashion where best-in-class services are bought and sold among banks and vendors to service targeted customer segments.  But, the march to replace the the UBS has begun. 

More interesting is to determine what, if any, CBS functions are really needed any longer.  The Millennials appear to be saying they do not care about the nuanced features we perfected and used to differentiate or products from the competition at a time when life was not digital.  They just want an account with basic core functions.  Differentiation is handled on the front-end with service levels like nothing we have seen since the days of personal, customer care in the bank branch while interacting with the world's best CRM tool, our local banker.  With technological/digital focus on customer care and mobile devices to deliver the goods, only now, we can expect to be fully satisfied by the level of care provided by FIs in the digital age.  Technology is no longer about the cost/income ratio but  rather digital customer engagement and lifetime customer value. 

Eventually, the CBS services will be distributed micro-services delivered by highly specialized teams/systems capable of flexing and scaling their product(s) to the demands of the consumer.  Banks will specialize and segment the markets in order to cut costs and up their game for "their" target customers.  

My guess is 10 years to reach the tipping point and another 10 before today's CBS is fully retired.  

Agreed.  In 2007, I was issued a MC branded pin-only-debit card by an Austrian bank.  The number on the face of the card is merely a reference number.  It has no magstripe and the chip contains the real number.  The point is that everything you mentioned is possible but requires the market players to adopt it including the consumer.  

Payment markets are set to fragment in its deployment of cards and other payment solutions.  Europe has/will regulate standards with the implementation of PSD2 and ultimately disintermediate cards altogether.  

Mobile will help us accomplish fit-for-purpose via instant issue, HCE, user driven card consoles, new security features like 2Factor, etc.  The thing to remember is from where we came.  Today security concerns and CNP e-comm are ubiquitous and card issuers have been unwilling to set limitations of use that would diminish the use of cards.  Top of wallet with interchange income is more important that fraud losses.  With thieves continuing to improve and payments becoming more competitive, the evolution will only continue.  

Improvement is, in this case, the enemy of Innovation.   

That is a strong rebuke for a standard that recently celebrated its 10th anniversary.  The standard sets out requirements and ongoing process for segmenting comm networks having sensitive data, encrypting the issuing and acquiring data bases, and encrypting the channel/message and tokenizing the payment credentials.  

Every player (cardholders, banks, merchants, acquirers, processors)  in the payment value chain is susceptible to criminals trying to steal the data; thus, we all must take responsibility for our area.  If anyone in the chain fails to provide sufficient protection, we all lose.  

Large and small merchants alike need only take a certified POS device from a certified provider and avoid doing anything to circumvent the built-in security. Problem solved for a few hundred quid.  Of course, as the data is needed to manage ones business, careful management of payment credentials is an absolute requirement that is all too often overlooked (50% apparently).  

The focus for the past few years has been to "devalue the data", making it useless to the criminal.  Preventing access to data and sufficiently encrypting and tokenizing the same will eventually have the desired result if the standards are applied.  I encourage you to make use of the standards and resources available in the market today. 

Alternatively, I would like to know your thoughts on what is now "fit for purpose", today?

Banks, if not everyone, expect physical security (Access and Identity); yet, most banks do not own the space but host/house with data centre providers in dedicated rooms or cages.  These environments are heavily partitioned, physically separated and firewalled.  Sensitive customer data and card data environments have layer upon layer of security features to prevent intrusion from in or outside the organization.  The nature of these large banking systems/software and hardware make secure, resilient, cloud deployment an impossible task today.....but it is coming.

Regarding the other topic: Sorry, I was using "Google" as a verb.  J

Look for articles like these:  

https://www.theregister.co.uk/2017/03/01/aws_s3_outage/

https://www.theinformation.com/how-aws-stacks-up-against-rivals-on-downtime

https://www.geekwire.com/2017/microsoft-says-googles-cloud-reliability-claim-vs-azure-amazon-web-services-not-compute/

Taking these at face value would suggest you need to plan for some unplanned downtime.  

Various banking corporate networks and underlying data are well suited to the cloud.  Other, more sensitive data rightly demands greater protection.  Makes me think that Monzo's card issuing, authorization and exception handling are not cloud based but tightly secured according to PCI DSS standards.  Other sensitive account and password data should be handled very carefully, if not in a private cloud, as well. 

As for resilience, Google "cloud downtime statistics" and you will see all the major services have significant outages that impact top companies across continents.   That should not happen in high availability environments.  Cloud must perform better.  

Operational challenges are the final issue.  Banks have very large, sophisticated software stacks that require specific release management, testing and promotion that is further complicated by cloud solution.

All these challenges are being addressed by the cloud providers (and software vendors) who will eventually succeed in closing each and every gap.  The banks will be eager when entire solutions are fully available.  In the meantime, it is comforting to know that banks are not penny-wise and pound-foolish on this topic.  

The transition has started with the challengers like Monzo.  How long before high street banks are 100% cloud?  

To the extent everyone cludged their middleware/ ESB does help the case, but enterprise scale, security, and resilience of a well-architected infrastructure remain the best answer for universal bankers. As micro-services are packaged together in great numbers and volumes, we are likely to find those drawbacks you mentioned in the last sentence.  

Correction:  2nd paragraph, 1st sentence:  The scope of SCA was originally directed to SEPA direct payments

Jeremy, 

Market-driven use cases (bank, consumer and merchant demand) and ubiquity of the card-based payment method defines the landscape today while  IDeal is a proven competitor of e-commerce and even face-to-face card payments.  It could even be argued that it is the model for PSD2 as defined by the EPC.  Such schemes have their place and are being emboldened or redefined by the PSD2.

The scope of SCA was originally directed to PISP and was expanded to all electronic payments including e-comm, mobile and unattended.  This change or lack of definition in scope raised many questions about how existing payment methods might be impacted by PSD2 requirements.  

Market forces around e-commerce are constantly optimizing profit, fraud risk and abandonment/conversion.  The Dutch model is so much more than IDeal.  It includes cultural norms, banking regulation, criminal code, enforcement, scale, and many other supporting factors that may or may not exist in other countries.  Card schemes have long dealt with this reality through its rules and technological advancements.  Back in the day, card fraud was minuscule.  The threats to IDeal is not fully known and it cannot be applied to all markets or use-cases.  If card numbers are the key to accounts, what are the bank account numbers found on practically every invoice in Europe?   

PISP coupled with universally available direct debit/credit across SEPA opens a floodgate of possibilities and venerabilities.  Wisely, Strong Customer Authentication, SCA, is required.  How and when it is implemented and for which payment types requires more thought and consideration to market economics.  As PISP