Tagged: psd2 Toggle Comment Threads | Keyboard Shortcuts

  • @fintechna 12:18 am on January 17, 2018 Permalink | Reply
    Tags: , , , , , , , psd2, ,   

    What You Should Know about Europe’s Big Payments Regulation PSD2 

    EXCLUSIVE &; After more than two years of planning, Services Directive II or finally arrived in Europe on Saturday. The has been dubbed as one of the more substantial regulatory changes of its kind in Europe. While many traditional and FIs might not be thrilled having to open their APIs [&;]
    Bank Innovation

  • @fintechna 12:19 am on January 13, 2018 Permalink | Reply
    Tags: , , Arrives, , , , psd2,   

    Payments Regulation PSD2 Arrives in Europe 

    EXCLUSIVE &; Major European , is set to go live tomorrow in . across the European Union have been preparing for the revised Payment Service Directive or PSD2 since it was first passed in 2015 by the Council of the European Union. The main objective of this new regulation is to level [&;]
    Bank Innovation

  • @fintechna 3:35 am on December 21, 2017 Permalink | Reply
    Tags: , , , , , , establish, , , , psd2, , vital   

    Why PSD2 and Open Banking make it vital to establish industry standards for APIs 

    Major changes are underway in Europe’s payments landscape. In the UK, the Competition & Markets Authority (CMA) has triggered a fundamental reshaping of the UK’s digital financial ecosystem through the regulation. And in the EU, the (Revised Payment Services Directive) regulations—coming into force on 13 January 2018—require to open their systems to third parties, and provide interfaces for them to initiate payments and retrieve account information.

    However, PSD2 leaves open the details of the application programming interfaces () that third parties will use to connect with banks. While the CMA has required British banks to set up an independent implementation entity called Open Banking Limited, the European Banking Authority’s (EBA’s) draft Regulatory Technical (RTS) for PSD2 specifies only technical framework conditions and no interface standard.

    As a result, cross-bank or pan-European API standards have yet to be clarified. Creating these standards is : PSD2 aims to develop a unified, innovative, pan-European digital ecosystem for financial products—and uniform interfaces and processes are essential for achieving this goal. So the lack of an implementation entity for the EU is a significant gap.

    To help fill it, the Berlin Group—consisting of almost 40 banks, associations and Payment Service Providers (PSPs) from across the EU—has defined a common API standard called &;NextGenPSD2&; for the use cases specified in PSD2. Initiatives are also being launched in Poland, Slovenia and France. However, given that the standardisation initiatives of the Berlin Group and Open Banking are the most advanced, it makes sense to compare these two frameworks to identify their main differences. Here they are:

    USE CASES COVERED: Open Banking supports the use cases &8220;Payment Initiation&8221; (PSD2 article 66) and &8220;Account Information&8221; (PSD2 article 67). The Berlin Group covers all PSD2 use cases by adding &8220;Fund Confirmation&8221; (PSD2 Article 65).

    DATA FIELDS: Working with numerous EU banks, the Berlin Group analysed various online banking masks to create a minimum standard set of data fields which all banks must offer via their APIs. In contrast, the Open Banking standard was negotiated only among the CMA9 banks and a UK third-party advisory group, and provides more extensive information, including on balances and available balance types that are particularly relevant to fintechs.

    CONSENT MODEL: Open Banking allows the customer to allow specific data clusters for use by third parties – for example, only account balances, deposits or direct debit transactions. This approach is close to the data minimisation requirements in the EU General Data Protection Regulation (GDPR). The Berlin Group provides for consent only for account balances and transaction histories for a certain period.

    MESSAGE FORMATS: The Open Banking Standard uses only the JSON (JavaScript Object Notation) format with field names based on ISO 20022, while the Berlin Group offers alternative industry-standard formats. On top of JSON, Berlin Group supports JSON with encapsulated ISO 20022-based pain.00x for payments and camt.05x and MT94x for account information.

    AUTHENTICATION: Open Banking supports strong customer authentication (SCA) through the &8220;redirect&8221; approach, while the Berlin Group offers two more approaches: “decoupled” (using a dedicated bank app), and “embedded” (the name of the customer is carried directly through the bank API).

    USER EXPERIENCE: In addition to the API specifications, Open Banking standardises the user experience and text modules in the click route, unifying consent issuing, authentication (2FA) and account information/payment authorisation. The Berlin Group allows each bank to devise its own user experience.

    TRANSACTION RISK ANALYSIS: The Transaction Risk Analysis defined in the RTS is supplied differently, with Open Banking offering more parameters via the API.

    While these are the main differences at this time, the gap may narrow. For example, the Berlin Group is expected to incorporate requirements in the final version of its proposals, scheduled for publication by the end of 2017. It’s also important to remember that implementing a standard does not automatically make a bank PSD2-compliant, since it still needs to comply with other aspects of the RTS like authentication methods, exemptions from SCA and API testing systems.

    The EBA’s RTS is expected to be ratified by the European Parliament at the end of February 2018, after which banks and other PSPs will have 18 months to implement it—including providing APIs. In choosing between the available standards, banks should make their evaluation as early as possible and take strategic and technical aspects into account so they can hit the ground running. Time is short—and having the optimal APIs in place will be critical to success in the PSD2 world.

    For additional information, see our report, PSD2: Defining new customer journeys

    My thanks to Hakan Eroglu for his research and analysis for this blog.

    The post Why PSD2 and Open Banking make it vital to establish industry standards for APIs appeared first on Accenture Banking Blog.

    Accenture Banking Blog

  • @fintechna 1:23 pm on July 24, 2017 Permalink | Reply
    Tags: , , psd2, Scoping,   

    PSD2: Scoping out the impacts of the RTS 

    The regulatory technical standards for strong customer authentication (SCA) and secure communication (SC) are proving difficult to finalize. Circulated in draft in 2016 for consultation, the EBA published its final draft in February 2017, followed by amendments requested by the European Commission, subsequently rejected by the EBA in June 2017.

    The key sticking point is the use of screen scraping. Although PSD2 is -neutral, the EBA banned screen scraping in its final draft, whereas the EC wants to allow it (on a contingency basis).

    PSD2: Scoping out the impacts of the RTS fintech

    As it stands, agreement on the final text for the RTS between the EBA, EC and European Parliament may extend into August or September 2017, and with RTS coming into effect 18 months later, now Q1 2019 is the earliest.

    PSD2 itself comes into force on 13 January 2018, and while there has always been a well-flagged gap from this date to when the RTS for SCA/SC come into force, the confusion over finalizing the RTS has led some PSPs to question if PSD2 itself will be delayed.

    However, PSD2 is still slated to become law across the EU in January 2018, and PSPs have to be compliant with it by then. In the EC’s amendments to the draft RTS, their accompanying explanatory notes state that the RTS and security aspects of PSD2 articles 65 (confirmation of funds), 66 (access for payment initiation), and 67 (access for account information) are applicable from the same date as the RTS, which may have led some to believe the EC wants these key articles on account access to be delayed.

    However, the EBA’s rejection of the EC amendments notwithstanding, it is only the RTS and security aspects of these PSD2 articles that the EC wants to apply from 2019, not the whole of each article—the rest of the provisions in these articles would still be mandatory from 13 January 2018.

    In fact, the reality is that the final draft of the RTS is not law until the EC, EBA and EP (parliament) are in agreement, so as it stands now, all provisions in all PSD2 articles are applicable from January 2018.

    Banks and other PSPs therefore need to be PSD2-compliant from 13 January 2018, with the following implications:

    1. Effective January 2018, they need to allow TPPs (AISPs and PISPs) access to online accounts without any contractual agreements.
    2. The method of access is the bank’s decision—realistically, it can be either through open APIs or through allowing TPPs to screen scrape (up to the RTS implementation date, and beyond if screen scraping is allowed after that).
    3. The security, authentication, fraud monitoring and secure communication methods (covered in the RTS) are the bank/PSP’s choice, between January 2018 and the RTS date (in 2019).

    /PSPs may have bilateral agreements with TPPs after January 2018, but they must also allow access to TPPs without a contract as well.

    Banks/PSPs therefore have two choices beginning January 2018:

    1. Do nothing, except allow screen scraping on their online accounts. If the final RTS text does eventually allow screen scraping from the RTS date, then they can choose to continue this method indefinitely.
    2. Implement an API management system and publish APIs. We encourage banks and PSPs to go this route if they are to be relevant and active in an API and Open Banking economy.

    If a bank is not ready with APIs by January 2018, it’s OK—provided they allow screen scraping. But they risk being excluded from TPP services that only use APIs, giving an advantage to competitors who do provide APIs.

    PSPs face further challenges:

    1. in developing automated mechanisms in their communities to validate authorized and regulated third parties who request access to their accounts;
    2. in authenticating customers and managing their consent, both with open APIs and with screen scraping (including long term solutions if screen scraping is allowed in the final RTS text); and
    3. in making TPPs accountable and liable for any breaches of consent or data access, or fraudulent payments that are the fault of the TPP.

    However, PSD2 compliance is independent of these challenges, which do not impact the need to be compliant in January 2018.

    To request a copy of our detailed report on the impact of PSD2 RTS, please contact Lakshmi Kv or Jeremy Light.

    The post PSD2: Scoping out the impacts of the RTS appeared first on Accenture Banking Blog.

    Accenture Banking Blog

  • @fintechna 12:56 pm on May 11, 2017 Permalink | Reply
    Tags: , , , , , 8364, , Geopolitics, psd2   

    The Geopolitics of PSD2 

    The Geopolitics of PSD2 fintech

    I sat down with the marketing team at Anthemis to discuss the opportunities and geopolitical challenges of open finance. This is the third part of a series of five articles. You can find part one here and part two&;here.

    So John, You&;re our in-house expert on . You&8217;ve said before that it&8217;s broadly misunderstood. Care to elaborate?

    Sure. , customers, consultants, politicians and start-ups don&8217;t understand PSD2. They think that they do but they don&8217;t. They understand the aspect of it immediately relevant to them like strong auth or licensing requirements but they&8217;re yet to piece together the broader implications.

    What are the broader implications?

    Well, step back. First consider the motivations for the legislation. PSD1 was about increasing payments competition and reducing cost. Banking licences protect banks when it comes to deposits business because it&8217;s of systemic import but why should it give them an unfair advantage anywhere else right? PSD1 wasn&8217;t a failure but it failed to do everything it set out to do. It&8217;s fair to assume then that PSD2 would be a direct continuation of PSD1, correcting the course and setting mistakes right, but it&8217;s&160;not.

    What do you mean, why&160;not?

    PSD1 was formulated and signed off on prior to the financial crash. A lot has changed since then. E.U. rehabilitation and growth has lagged behind the rest of the world, youth unemployment in the region continues to grow, political unrest is destabilising the continent, the progressive socio-economic pledge of Europe is being challenged and vitally, Europe has failed to develop any new corporate global powers for the digital&160;age.

    The E.U. understand that 1) massive amounts of European capital flow to the U.S. every year in the form of digital and technological consumer goods and services, 2) huge amounts of European citizens&8217; data now sits on U.S. company owned servers and 3) regional jurisdictional data, payments and identity infrastructure is inevitable and the most effective way to manage those threats is by giving would-be-global European firms a competitive edge in the form of regulation. In a way, PSD2 is a new, particularly European, kind of trade tariff. One that requires a certain level of sophistication to gain&160;entry.

    So is PSD2 about payments or a U.S.&;&;&8202;E.U. trade dispute or&160;both?

    It&8217;s both. In many ways it&8217;s the most avant garde financial regulation of our time whilst also extending a long middle finger to our American cousins. The changes to the regulation on direct account to account payments and four party payment schemes show that American card schemes are obviously unwelcome in Europe in their current form but I suspect that Facebook, Apple et al will also continue to fall afoul of both the EBA and the GDPR. It&8217;s worth remembering that two weeks after Apple, America&8217;s biggest company, were ordered to pay &;13bn in back taxes in Europe, Deutsche Bank, formerly Europe&8217;s biggest bank, were fined $ 14bn in New York. That&8217;s quite the coincidence.

    Why? I thought we&8217;re friends with the&160;U.S.?

    Of course we are. That&8217;s not the point though. Creating global European digital businesses is the fastest possible way to solve for Europe&8217;s stagnant growth and unemployment problems. Europe needs to become more digital and finance is an amazing place to start. It&8217;s long been what we&8217;re best at anyway. The important take away is that global banking is becoming increasingly heterogeneous. An industry that used to be broadly similar in every part of the world is becoming increasingly distinct. Africa focused on mobile, Asia innovating without regulation, Europe innovating through regulation and North America relying on the market to fund start-ups that can circumvent retrograde infrastructure.

    So it&8217;s not just about XS2A&160;then?

    No it&8217;s not just about XS2A. People have become obsessed with XS2A due to the potential implications but that&8217;s just one small part of the legislation and to be honest it&8217;s not even close to the most significant piece of&160;it.

    Will any of this impact roll&160;out?

    My expectation is that, due to the broader ramifications, there will be significantly less leeway given to banks who don&8217;t comply on time. Additionally, I expect that the banks who produce a full suite of premium APIs in in time for the roll out of the mandated standard payment APIs will have 24 months of runway ahead of their peers before they can even begin to catch up. It&8217;s likely to be the beginning of the thinning of the&160;herd.

    The Geopolitics of PSD2 fintech

    The Geopolitics of PSD2 was originally published in hackingfinance on Medium, where people are continuing the conversation by highlighting and responding to this story.

    Bank Innovation

  • @fintechna 1:47 pm on April 2, 2017 Permalink | Reply
    Tags: , , , effectively, , , psd2,   

    How banks can deal effectively with the security & fraud impacts of PSD2 

    With the introduction of , a new era of secure payments has begun in the European Union. The new regulation is aimed at enhanced customer protection against , with stringent liability and accountability requirements and strong customer authentication features.

    How banks can deal effectively with the security & fraud impacts of PSD2 fintech

    Read the report

    PSD2 requires European and other payment service providers to allow customers’ accounts to be accessed via
    application programming interfaces (APIs). Their customers are able to initiate payments from their accounts directly from third-party apps and websites, and to share transaction and balance information with third parties.

    The directive provides measures to protect the confidentiality and integrity of personalized credentials. Banks will now be authorized to block third-party access to accounts if they detect unauthorized or fraudulent activity. At the same time, providers who fail to authenticate a transaction appropriately will now be held liable for any resulting breaches.

    So, what does all this mean for the incumbent players in the European financial services landscape?

    Accenture has identified key challenges that banks will need to deal with in the short term:

    • After PSD2, many customers may start relying on Third-Party Payment service providers (TPPs) for banking transactions, making it more difficult for banks to detect fraud.
    • By providing their APIs to TPPs, banks open up a significantly greater attack surface to potential cyber adversaries, and can no longer hide critical applications behind perimeter firewalls.

    With the new directive also come opportunities:

    • PSD2 encourages banks to embed security up front in the new systems and APIs, thus turning security into a business asset.
    • Creating systems with open APIs gives banks the opportunity to strengthen their fraud prevention capabilities—by blocking attacks high up the stack and protecting the intelligence located on lower layers.

    Accenture recommends five actions for banks to deal effectively with the challenges and opportunities of PSD2:

    1. Make API security an integral part of PSD2 implementations, and ensure that security controls for APIs are at par with digital banking.
    2. Adopt a user-driven authentication framework that doesn’t disclose user credentials to TPPs.
    3. Use biometric technologies for authentication, as that will not only address the PSD2 requirement for more accurate validation, but will also provide a better consumer experience.
    4. Assess customers’ location and behaviour against their usual patterns to gain a clearer view of the risks and the level of authentication required.
    5. Follow these principles while designing APIs:
        • Show respect for user privacy and design in consent management controls.
        • Embed privacy into design and use maximum privacy as the default setting.
        • Maintain transparency of operations of the IT systems.
        • Deny access to information that isn&;t absolutely necessary, or that the user has not agreed to share.
        • Strive to detect and prevent privacy-invasive events before they happen.

    Read more about this in our latest report, PSD2 & Open Banking | Security and fraud impacts on banks: Are you ready?


    The post How banks can deal effectively with the security &038; fraud impacts of PSD2 appeared first on Accenture Banking Blog.

    Accenture Banking Blog

  • @fintechna 10:00 am on February 6, 2017 Permalink | Reply
    Tags: , , , psd2,   

    Will the API Economy breed a Credit Card/ACH hybrid after PSD2? 

    Will the API Economy breed a Credit Card/ACH hybrid after PSD2? regulation

    is creating a new distinct species for retail digital payments in the EU. Shared by account servicing and third party payment initiators, there will be a customer-triggered Credit Transfer for transferring funds from a customer’s account to that of the Merchant providing the goods or services. Upon receipt of payment, the merchant ships the goods/releases the service. By relying on bank security, this method of payment is hard for fraudsters to replay elsewhere, the speed is moving to “immediate,” and there is an irrevocable payment to the merchant. Unlike a credit card, the method does not offer any repudiation mechanism and does not facilitate reversals or refunds. This new species will only live in the EU. Much of the underpinnings for PSD2 comes from the SEPA elements of the Economic and Monetary Union project in the EU.

    This newly bred species faces entrenched competition from a dominant older Card species that has ruled the consumer payments Savannah globally for over 50 years. The DNA of this species is from the US. There are US firms in leading positions globally in the main elements of the payment card value chain. US-born VISA and Mastercard as Card Schemes are effectively the franchisors of the card payment ecosystem.

    Although banks across the globe issue payment cards to customers, the highest volume issuers are typically US banks. Issuers introduce consumers into the card payments ecosystem, under license from the card payment schemes. Acquirers are responsible for capturing the POS transactions and submitting these transactions to the card scheme for authorisation. If the consumer has the funds or the credit, this process leads to the merchant receiving the value of the goods or services sold. There is also an extensive and distinctive value chain supporting Merchants.  Acquiring Processors provide sub-supply for Acquirers, and US firms are global leaders in this activity. There is a deep sub-supply value chain for Acquirers, with US expertise often to the forefront. The Point of Sale (POS) or Gateway providers offer hardware and software services for the secure capture of payment card details. POS or Gateway providers often innovate in adjacent categories to card payments such as retail inventory management and cash register software. US-led investment is also to the forefront in this area.

    Within all these moving parts, there are processes that are relatively unique to the card schemes, such as , rules, penalties, standards, procedures, brand guidelines, financial settlement platforms, security protocols, chargebacks, holds, stand-in processing, reserve accounts, minimum monthly payments, interest-free periods, etc.

    It is interesting to speculate about what Merchants would ask for if they could pick and choose their best possible combination of features from both species.  Here are a dozen simple and crude requests that a Merchant might make if they could define a hybrid payments collection service between ACH and Cards:

    1.      “If the customer pattern moves to bank-to-bank credit transfers after PSD2, as a Merchant I want to see the same share of my sales being funded by unsecured consumer credit as when I saw a Debit Card/Credit Card split. I want customers to have still the same opportunity to buy on credit if some or all of my product range is priced at high values. “

    2.      “Even if banks start to provide credit through unfunded bank accounts rather than card limits, I want my customers to have still the type of structured credit agreements that they liked with Cards, such as minimum monthly payments and interest-free periods. Ideally, they should get to choose the optional elements of their credit agreements.”

    3.      “I reluctantly accept that I have to carry the overhead of a trusted dispute resolution mechanism for higher value purchases. I want my provider to educate the customers properly on when this protection exists and when it does not exist. “

    4.      “I do not want any repudiation mechanism for the consumer for small value transactions. I have my statutory obligations built into my complaints and refund processes.”

    5.      “I want the low-value purchases made without credit paid to me immediately.”

    6.      “I want the simplicity and predictability of ACH pricing, not an array of fixed, variable, tiered and once-off card charges.”

    7.      “I do not want “holds” put on my money if the business is unexpectedly good compared to projections nor do I want to have money retained in “reserve accounts” in case of chargebacks. My bank should do all the due diligence on my activities, and that should be enough.”

    8.      “I do not want to store the digital credentials of my customers, and I do not want to have to comply with a “PCI” security standard that could bankrupt my business with fines and penalties. I am a retailer, not a professional cyber-security company or a bank.”

    9.      “If the customer is buying from me remotely on a mobile phone, I want minimal delays and friction but also strong customer authentication with the minimum of variation for transaction size and payment type. These security controls should be so elegantly designed that only thieves and fraudsters abandon transactions.”

    10.  “I want value-added services that come with my point-of-sale payment collection services, such as inventory management software, cash drawers, and an App Store, especially for retailers. I want these value added services to work with all payment types.”

    11.  “I want working capital finance opportunities that capture all my trading process delivered seamlessly to my business at POS. I don’t want offers of finance that are specifically confined to Cards traffic or some other specific payment mechanism ”

    12.  “I want payment schemes with great brands that are recognised globally and entice consumers from all locations, not just EU.”

    Producing a hybrid scheme of this agility and desirability is a very tall order, given that the most important suppliers tend to have their capital, infrastructure and knowledge tied up in one of the two models. The biggest EU banks that will handle most of the PSD2 payment initiation volumes are very mature organisations with monolithic software platforms. The major card processors and platforms are also large and mature organisations with monolithic software platforms. They also have very distinctive knowledge bases, focused on either Cards or ACH. They look out at the world from within this history, with a perspective of customer needs influenced by their current model.

    Given these rigidities, is a hybrid model that might delight Merchants a pipedream? Perhaps not, if the theoretical promise of the “ ” becomes a reality. The API Economy is a set of business models and channels based on secure access to functionality and exchange of data between businesses through Open APIs.   An Open API is a publicly available application programming interface. It provides third-party developers with programmatic access to a proprietary software application. APIs can also be used within businesses to clearly define automated methods of communication between various software components.

    API advocates make many claims about their usefulness. They argue that APIs lower barriers to entry for programmers. They make designing complementary programs easier and faster. Modular design, enabled by APIs, allow software designers to create, modify and remove components. Modularity combines the standardisation needed for high volume processes with customisation required for bespoke design. APIs also enable measuring and metering the third-parties that are accessing and using these resources.

    Both Banking and Card Processing specialists are in mature industries with many monolithic systems and divisional organisational structures. All mature industries face a range of challenges adapting to Open APIs. They will have to modify performance management and measurement systems. They have complicated and expensive investments to make to develop modular software with a microservices architecture. Open APIs are entirely different to own-brand products in mature industries. The monetisation goals for Open APIs will have to reconcile with the goals of own-brand products. Mature industries with very established patterns of pursuing profits at divisional level might struggle to see where they will capture value from Open APIs. Older businesses that were not born in the networked economy can be excessively focused on the downside risk of data travelling out to third-parties.

    By definition, all of the service domains required for the market to assemble the Merchants wish list for “the ideal hybrid ACH/Card scheme” must already exist. In general, these services are locked inside the software architecture of the respective service providers, either banks or major card specialists.  These service domains have Machine to Machine and Human to Machine interactions.  Machine to Machine interactions has content suitable for data fields that can be passed between applications. The level of detail in the interactions influence the potential for Open APIs. These interactions contain identifiers and depictions that can be explicitly mapped to a data structure. The standard of detail is very high. Human to Machine interaction includes structured forms of information that are completed by a person during a service exchange. The API Economy has the potential to capture the Human input through more applications and more convenient applications.

    In crude conclusion, notwithstanding the difficulties for mature firms in changing their business models, Open APIs could revolutionise how data and services are distributed. Given the regulatory intervention, the Card specialists in particular seem to have an incentive to make some or all of their characteristic and value adding service domains available to all models, whether there are 3 or 4 parties involved in a scheme. It could be a 2-model world with tighter margins, so they need to profit from both models. If the reality of the API Economy matches the theory, we could see some hybrid species in the future.

    is Author, “PSD2 in Plain English” at Rohan Consulting Services Ltd.

  • @fintechna 3:35 pm on September 23, 2016 Permalink | Reply
    Tags: , , , , , , Directive, , , , , psd2,   

    EU’s Payment Services Directive (PSD2): What It Is And Why It Matters 

    Recent regulatory changes in Europe, including the (), are set to accelerate payments innovation.

    The Payment Services Directive (PSD) was initially adopted by the European Union (EU) in 2007 and aimed at providing a legal framework for all payments made in the region with the purpose of making these faster, more efficient and easier to use for European consumers and payments services providers.

    In October 2015, the EU adopted a revised PSD &; also referred to as PSD2 &8211; that sought to enhance consumer protection, promote innovation and improve the security of payments services.


    PSD2: What is it?

    PSD2 is a major policy development expected to impact the payments industry across Europe through: further standardization and interoperability of cards, Internet and mobile payments methods; the reduction of barriers to entry in particular for card and Internet payments providers, driving thus increased competition, innovation and transparency across the European payments market; as well as providing the necessary legal platform for the Single Euro Payments Area (SEPA).

    The directive seeks to improve the existing EU rules for electronic payments, while taking into account emerging innovative payment services, such as Internet and mobile payments. It sets out rules concerning:

    • Strict security requirements for electronic payments and the protection of consumers&; financial data, guaranteeing safe authentication and reducing the risk of fraud;
    • The transparency of conditions and information requirements for payment services;
    • The rights and obligations of users and providers of payment services.

    The regulation came into effect on January 12, 2016, and EU countries must incorporate it into national law by January 13, 2018.


    The impacts

    The new directive brings key changes that include:

    Third-party payment initiation: Payment Initiation Service Providers (PISP) will be able to initiate online payments from the payer&8217;s bank account. This will encourage competition in the European payments industry. Accenture estimates PISP services could account for up to 16% of online retail payments by 2020.

    The definition of a &;payment institution&; is extended to new types and categories of players. While the original PSD applied only to transactions occurring within the EU, the PSD2 will extend this scope to &8220;one leg out&8221; transactions.

    Third-party account access: The directive will regulate account information service providers (AISPs). These providers act as aggregators of customer payment account information.

    Prohibition of card surcharges: The regulation seeks to standardize the different approaches to surcharges on card-based transactions across the EU.

    Security of online payments and account access through the introduction of new security requirements for electronic payments and account access, along with new security challenges relating to AISPs and PISPs.

    The directive will affect everyone in the shifting payment landscape. This includes , fintechs, the PCI (Payment Card Industry) as well as merchants.

    EU’s Payment Services Directive (PSD2): What It Is And Why It Matters fintech

    How PISPs and AISPs will change existing interaction models between customers and banks, Accenture report &;Seizing the Opportunities Unlocked by the EU’s Revised Payment Services Directive&8217;

    PSD2 will bring both challenges and opportunities for European banks. Banks will be required to open up their infrastructure to third parties by offering APIs under the XS2A (access to account) rule. They will be forced to grant them access to their customers&8217; online account/payment services in a regulated and secure way.

    On the other hand, PSD2 presents significant opportunities to grow new revenue streams &8211; by facilitating and monetizing access to raw data and banking services, for instance &8211;, capture customer ownership and process toward an extended ecosystem centered on the &8220;Everyday Bank,&8221; a concept that takes banking to being trusted, indispensable and central to consumers&8217; everyday activities.

    EU’s Payment Services Directive (PSD2): What It Is And Why It Matters fintech

    EU banks: challenges and opportunities of PSD2, Accenture report &8216;Seizing the Opportunities Unlocked by the EU’s Revised Payment Services Directive&8217;


    Featured image: Mobile banking concept by Ditty_about_summer, via Shutterstock.com.

    The post EU&8217;s Payment Services Directive (PSD2): What It Is And Why It Matters appeared first on Fintech Schweiz Digital Finance News – FintechNewsCH.

    Fintech Schweiz Digital Finance News – FintechNewsCH

  • @fintechna 6:00 am on August 4, 2016 Permalink | Reply
    Tags: , cro, , open banking, psd2   

    Where are the likely “banana skins” for bank CROs from PSD2 and Open Banking? 

    Where are the likely “banana skins” for bank CROs from PSD2 and Open Banking? regulation

    In general, Chief Risk Officers (CROs) and Boards of Directors of traditional probably lose a lot more sleep over the health of bank balance sheets rather than the security and agility of daily payments and accounts processes.   A failure to control the quality of loans on the balance sheet is an existential risk for a credit institution.  A failure to maintain depositor confidence, leading to a cataclysmic outflow of funds from the liabilities side of the balance sheet, is also an existential threat.  While significant frauds, security failures and data privacy breaches may tarnish bank brands, slow business growth and lead to very large regulatory fines, these events have to be incredibly large and systemic to suddenly wipe out a bank’s equity or cause a loss of a banking license.

    Although banks may have ultimately adopted progressive API Strategies over time, banks are being compelled by to adopt API-driven business objectives and processes against a fixed deadline.   Without regulatory intervention, the timing of this change would have been commercially driven.  In more normal circumstances, the Boards of these banks could have approved new API Strategies (covering API provision and consumption) with a defined appetite for risk.    This is the level of risk that a bank is willing to accept in order to deliver these business objectives.   It will be important that the mandatory nature of PSD2 does not inhibit banks from carrying out these important disciplines.  Even a “comply only” API business strategy prompted by PSD2 does not mean that bank Boards are not ultimately responsible for the risk profile of these business activities. 

    To try to avoid adverse outcomes, bank management and Boards of Directors spend much time defining their appetite for risk.  To inform the process of defining risk appetite, banks invest much time and effort in developing risk models.  Many of these risk models are devised and prescribed from the “top down” by Regulators and prescribed to a class of banks, in order to compare risk profiles.  Risk models are also devised and implemented from the “top down” by and specialist risk management staff.     For example, banks model the adequacy of capital levels and loan loss provisions in adverse economic conditions (often under regulatory supervision, such as the recent Stress Tests conducted by the European Banking Authority). These models help inform CRO responses – can and should risks be avoided, reduced, shared or accepted? 

      , the author of this post, is also author of “PSD2 in Plain English”.

    Where are the likely “banana skins” for bank CROs from PSD2 and Open Banking? regulationWhere are the likely “banana skins” for bank CROs from PSD2 and Open Banking? regulationPSD2 in Plain English (Payments Landscape
    for Non-Specialists) (Volume 1)
    Where are the likely “banana skins” for bank CROs from PSD2 and Open Banking? regulation

    PSD2 and is not a matter of a faster growth rate or a diversification into new market segments, using established business processes and risk models.   In broad terms, PSD2 is extending and blurring the boundaries of a bank.  With PSD2 and Open Banking, there are now new risks to a bank’s risk profile outside of contractual arrangements that the bank has chosen to enter.   It could be difficult for bank CROs to fully understand and fully embrace the lessons from risk management problems inside PSD2’s “Third Party Providers (TPPs)”.

    Does a bank’s CRO have a big blind spot in this new Open Banking environment?  As the layer of overlay Payment Initiation and Account Information services grows into an ecosystem, the capability of the CRO to quickly identify where a fraud could happen or how a fraud was executed will fall.  The possible points of weakness increase as more and more payment initiation is captured by the risk management and security of TPPs.   There may be many TPPs for a certain type of payment or a certain device or security protocol that is breached across many TPPs.   Calls from puzzled customers to a bank’s Call Centres will have many more scenarios to plan for and many more scenarios to try to understand. Call Centres will ideally have to know exactly the TPPs, current and lapsed, that a customer has granted PSD2 access to.  Call Centres and Client Education will probably have to prepare and plan for the emergence of imposter TPPs.  The normal patterns of API calls on a bank’s payments hub will have to be tracked as accurately as the normal pattern of customer instructions through proprietary channels,

    The initial risk model prepared for PSD2 and Open Banking will have to come from the “bottom up”.   Staff managing business units with expert knowledge of a certain set of products and processes can model their risk profiles from the “bottom up”.   These models are used across a range of risks to help banks identify and manage the risks that they are running.  A very common model is a “Risk Matrix”.  It is a simple mechanism to increase visibility of risks and assist management decision making.  The severity of an event could be classified as Catastrophic, Critical, Marginal or Negligible.  The probability of an event occurring might be categorised as ‘Certain’, ‘Likely’, ‘Possible’, ‘Unlikely’ or ‘Rare’.  It is likely that the technical function that physically manages the Private, Partner and Public APIs will be documenting new risks from newly published APIs on their unit Risk Matrix.  The commercial function or functions that have line of business responsibility for API Monetisation and PSD2 compliance will probably be documenting different PSD2 risks a different Risk Matrix from a commercial perspective.  

    The initial risk model will have to correctly identify and maintain the correct number of Payment Accounts that must be exposed by law. Banks will need to ensure that new controls are designed and effectively implemented so that TPP Permissions can be revoked by End Users who hold accounts at the bank. API Related Complaints by End Users or by API Developers will need to be monitored as potential indicators of risk.   Managing data and privacy (both of customers and API Developers) appropriately in an Open Banking environment is a risk.  If an API is temporarily or permanently withdrawn, a bank will need to understand the implications of that action.    When significant actions or first-time processes are triggered by the end users, banks will need to be sure that Out of Band Challenges will go to End Users.  API Permissions with an expiry date will need to expire on the time limit. If there is a dispute over a potentially unauthorised payment through a Payment Initiation Service, banks will need to be sure that PSD2 is being observed and an immediate refund is triggered.  In the early days after PSD2, there is no “typical” or “average” number of risk events to guide a bank’s risk responses or risk appetites.  Banks will also be required under PSD2 to share information on security threats.   There will be guidelines for managing security incidents and the EBA will set guidelines on how to handle complaints.

    In the early stages of Open Banking, volumes will be low.  A key driver of the “severity” weighting that bank staff will use on a “Bottom Up” Risk Matrix will be both the volume and the value of the transactions that are traveling through this process.  Relative to the volumes that currently travel through a bank’s proprietary channels and the enormous values of payments through a bank’s Treasury function, the initial Open Banking traffic is likely to be initially classified as “Marginal”.  CROs may not see Amazon, Apple, Google, Facebook and Microsoft appear in the Overlay layer of TPPs in the first few months of the PSD2 and Open Banking regime.  However, it is probably a mistake to assume that all “Fintechs” are small and undercapitalised, thus unlikely to trouble a bank’s infrastructure with a surge of volume.  “Silicon Valley” TPPs will have pan-EU ambitions and have potentially large appetites for API consumption.  Crucially, EU banks could find that 80% of their installed base of customers already trust and actively use services from these giants. 

    We can reasonably speculate that the crooks and fraudsters that exploit opportunities in digital services could have their own “PSD2 projects”.  What sort of new attack vectors for fraudsters could exist in this new, more complex environment?  Fraudsters can read the new PSD2 legislation just as well as anyone else.  The fraudster knows that a bank has only one working day after a disputed payment to refund any unauthorised payment transactions generated by a TPP.    Fraudsters will know that banks will have to deal with potential payment reversals within the TPP process while an impatient customer has launched a fresh effort at the same payment through a traditional channel.   eCommerce or Mobile Commerce transactions that historically only appeared as Card transactions will start to appear as Faster Payment Scheme Credit Transfers, disrupting and confusing customer payment profiles held by banks. Fraudsters could start to watch for authentication and control differences between TPP processes and traditional processes, building up a trusted profile for subsequent exploitation on the other process.  Fraudsters will know that sensitive personal or authentication data extracted from unsuspecting TPP customers could later be used in a bank’s proprietary channels without the account servicing bank being aware of the initial breach.    

    In crude conclusion, the initial risk profile of PSD2 and Open Banking looks quite benign compared to some of the existential risks that banks face every day.   However, as PSD2 and Open Banking starts to gain market acceptance and volumes start to ramp up, the “banana skins” will come quite quickly.  CROs and Bank Boards will have to recognise that a new business strategy like exposed APIs has to be rigorously scrutinised for risk, whether this new business strategy is enforced by an EU regulation or not.  Banks will have to prepare for the new PSD2 and Open Banking regime without any tested and mature risk models. The blurring boundaries of the organisation make a “top-down” identification of material PSD2 risks a difficult challenge for the CRO.  Risks related to PSD2 and Open Banking will not be confined to one business unit, making the “bottom up” risk profile more blurred. At an industry level, there will be a period of time before a “sensitivity level” is established for the risk profile of Open Banking processes. The addition of 5% of a bank’s total payments volumes through TPPs in immature processes may be a “marginal” change in payments volumes but it probably does not represent a marginal change in the bank’s overall risk profile.  The structure of PSD2 means that Silicon Valley giants could arrive with very large volumes and effectively unannounced, without having any prior relationship with the API publishing bank. Fraudsters will know that the addition of new overlay services managed by TPPs is a radical change in business model and is completely different to the incremental addition a new proprietary bank channel (such as tablet, mobile or kiosk) using the same proven customer profile and control processes.

    In crude conclusion, the primary risk control for banks in this environment can only be a risk-aware culture.   Bank management will have to seize growth opportunities from APIs while managing risk, just as in all other processes.   The immaturity of risk classification models, industry norms and fraud detection models will mean that bank management will have to approach this arena from “first principles”.   As API volumes grow, clear and active communication within banks and within industry bodies about the various “banana skins” will be crucial.   innovators seeking to build partnership relationships with banks in the Open Banking era should also welcome tough questions from banks about their risk control capabilities.  If a bank is asking tough questions and paying good attention to likely risks in the TPP overlay layer, that bank is far more likely to be serious about building an ecosystem out of its payment

    , the author of this post, is also author of “PSD2 in Plain English”.


    Where are the likely “banana skins” for bank CROs from PSD2 and Open Banking? regulationWhere are the likely “banana skins” for bank CROs from PSD2 and Open Banking? regulationPSD2 in Plain English (Payments Landscape
    for Non-Specialists) (Volume 1)
    Where are the likely “banana skins” for bank CROs from PSD2 and Open Banking? regulation

  • @fintechna 12:18 pm on June 24, 2016 Permalink | Reply
    Tags: , , , , enables, psd2, ,   

    How PSD2 enables the unbundling & rebundling of the bank 

    There are two types of regulation. One is just another annoying cost/process for the and a wonderful opportunity for consultants, lawyers, outsourcers &; IT providers. Another type of regulation fundamentally opens up the market for innovation and threatens the control of the incumbents. is the latter type. It is the key to&;the &;Read more How PSD2 the unbundling &38; of the&160;bankHow PSD2 enables the unbundling & rebundling of the bank fintech
    Bank Innovation

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc