Tagged: psd2 Toggle Comment Threads | Keyboard Shortcuts

  • user 3:35 pm on July 20, 2018 Permalink | Reply
    Tags: balance, , , , , psd2, , ,   

    How will biometrics balance payment security & convenience under PSD2? 

    The European Union’s new regulations, the General Data Protection Regulation (GDPR) and Second #Payment Services Directive (#PSD2), require secure transactions and data handling as well as good customer experience. PSD2, in particular, requires strong customer authentication (SCA) methods, which dictate “two-factor authentication” to ensure all payment approvals are in place. Two-factor authentication means that authentication of a customer’s identity must be based on two or more of these elements: knowledge (something the user knows), possession (something only the user has) and inherence (something the user is).

    The strict PSD2 RTS requirements may lead to friction in the payments process in online and POS (point-of-sales) checkout. Existing SCA methods such as SMS-TAN and iTAN will be considered non-compliant and not user-friendly. However, PSD2 aims to improve user experience and keep #security—namely inherence. Inherence is the element that allows leveraging of biometric data and mechanisms for SCA.

    Technological advancements are augmenting e-commerce payments and payments innovation methods, which further enhance the consumer appetite for seamless, frictionless and secure payments experiences. #Biometrics is one of the latest and most cutting-edge technologies being adopted. It’s usually integrated into applications to strengthen security and curb identity fraud. Fingerprint payment is the most common biometric payment method; however, experts predict that other systems—including face, eye and voice recognition—will become more widespread over time. The question is, are these mechanisms compliant with the new regulations and what do #banks need to consider about biometrics in a highly regulated business?

    The RTS indicates the following high-level criteria must be applied while assessing whether an authentication method qualifies as SCA:

    • Dynamic linking: All information about the amount paid and payment recipient must be passed on across all phases of the authentication. For biometrics, the numerical representation generated from the data points collected at the customer’s device needs to be dynamically linked.
    • Independence of channels: The channel used for the initiation of a payment or account information transaction must be separate from the channel used for the receipt of the authentication code.
    • Creation and validation within the bank’s environment: For biometrics, the creation of the templates needs to be performed in the bank’s environment. The software that collects data points from the device must also be provided by the bank.
    • Underivable authentication codes: The biometric data points collected from the device must be changed in such a way that every data point package can be considered a new “authentication code”, which is unique for every request and, at the same time, is capable of being verified by the bank in the matching process.
    • Non-disclosure: Biometric data points or raw data and matching templates must not be stored in the device or the bank to prevent reverse engineering of the raw biometric data.

    Customers and banks are keen to use biometrics

    Consumers are inclined toward using biometric solutions to protect their transactions because of their #convenience and speedy authentication process—and more and more banks are adopting biometric #technology as part of their identity verification process to improve user experience. The future of biometrics in the online payment process is promising.

    Innovation in biometric technology

    New technologies are now enabling rapid innovation in two areas of biometrics: visual biometrics (face recognition, fingerprints, finger-vein, hand/finger geometry and iris/retina recognition) and behavioral biometrics (dynamic signature verification, keystroke dynamics and voice recognition). Alongside the emergence of these new modalities, other innovations are also in development:

    • Biometrics as a Service (BaaS), which is based on sharing data with a remote server holding a centralized biometric database and offering biometric-based authentication as a service over the internet.
    • Biometrics and the Internet of Things (IoT), which enhances security for the millions of new devices joining an IoT network by combining passwords with an additional layer to achieve two-factor authentication.

    As biometric solutions gain momentum and uptake, they face challenges associated with their implementation, such as the need to comply with the PSD2 RTS requirements, technology to ensure the solution’s functionality and security, and the need to develop an ecosystem in which biometric methods are used in a consistent and standardized way, across multiple markets benefitting from network effects.

    Though not without its obstacles, adopting biometric payments provides a future roadmap for a seamless, safe and frictionless payments experience. It will be interesting to see how biometrics develops in the coming years, adapting to customer expectations and overcoming the hurdles of implementation.

    The post How will biometrics balance payment security &038; convenience under PSD2? appeared first on Accenture Banking Blog.

    Accenture Banking Blog

     

  • user 3:35 pm on June 2, 2018 Permalink | Reply
    Tags: , , , , , , , psd2,   

    Will PSD2 APIs and instant payments change the game in European payments? 

    The EU’s Second Payment Services Directive (#PSD2)—and the #European Banking Authority’s related Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Secure Open Standards of Communication—represent a turning point for existing business models in #payments in Europe. PSD2 and RTS open up #banks’ systems to third-party payments services providers (TPPs) for account information, payment initiation and confirmation of funds via an access interface such as application programming interfaces (#APIs).

    The final RTS published on 13 March 2018 specifies only the technical framework conditions and not interface standards. To help fill this gap, the Berlin Group—consisting of almost 40 banks, associations and PSPs from across the EU—has defined a common API framework called “NextGenPSD2” (current version 1.1) for the use cases specified in PSD2.

    The major impacts in this context include:

    Payment initiation opens up: For payment initiation, the NextGenPSD2 framework offers, amongst others, SEPA #Instant Payments (SCTInst) as a payment instrument. The combination of PSD2 and SCTInst has huge potential to disrupt existing business models, depending on the level of API standardization and penetration of SCTinst in the EU.

    Impacts on the cards business: TPPs such as merchants, #technology giants and PSPs could use the PSD2 APIs to make instant payments directly from customer accounts to the TPP bank account, bypassing card schemes and fees.

    Frictionless instant payments with PSD2: Customer experience is key in payments. Friction and slowness can reduce acceptance of the payment instrument on both the customer and merchant sides, leading to higher cancellation rates in eCommerce checkout processes and longer queues in the store.

    But there are issues with SCA—PSD2 APIs require banks to perform SCA on every transaction. This could lead to friction in the user experience at the point of sale (POS) and in eCommerce. PSD2 provides a convenient way to solve the issue of SCA through inherence and biometrics-based SCA methods. As innovation in this area continues, there will be a huge push towards creating RTS-compliant biometrics authentication methods.

    How banks can innovate

    TPPs such as tech giants and fintechs are not the only ones that could profit from PSD2 and instant payments—banks could also play an important role. Access to accounts and instant payments become commodity services with low or almost no margin for banks. New revenue opportunities will be in the value-added services and the platform ecosystems around these commodity services. “Going beyond PSD2” will include opportunities to monetize additional data and services combined with instant payments.

    Read my complete article at InstaPay for more insights and share your views.

    The post Will PSD2 APIs and instant payments change the game in European payments? appeared first on Accenture Banking Blog.

    Accenture Banking Blog

     

  • user 3:35 am on May 23, 2018 Permalink | Reply
    Tags: , , , , psd2, , stateoftheart   

    How banks should act now to build state-of-the-art APIs for PSD2 and beyond 

    On 13th January 2018, the second Payment Services Directive (#PSD2) came into force, defining a new chapter in the European payments market. It requires #banks to open their systems to third parties and provide interfaces to them to initiate payments on accounts, retrieve account information and a confirmation of availability of funds on accounts. Application programming interfaces (#APIs) play a vital role and standardized APIs are required to avoid fragmentation in the European market, and promote the digital ecosystem. PSD2 does not come with an API standardization. To help fill this gap, the Berlin Group—consisting of almost 40 banks, associations and PSPs from across the EU—has defined a common API standard called “NextGenPSD2”, which provides guidelines to reduces XS2A complexity. It is ready to be used by banks and TPPs for implementing PSD2-required bank account access.

    Berlin Group’s NextGenPSD2 is the leading API framework that helps banks to #build API standards. Since NextGenPSD2 does not specify one single API standard, banks #should follow basic principles of API design and build API standards that are state of the art:

    • RESTful JSON (full JSON format) for payments and account information by using standardized ISO20022 attribute naming conventions
    • Only a minimum set of data fields for the most relevant customer segments—such as retail, and small- and medium-sized enterprises (SMEs)
    • Single payment mode with all relevant payment products (such as SEPA Credit Transfer)
    • Embedded SCA approach (customer enters credentials at TPP side) and with full OAuth2-based SCA procedure

    Time is short. By 14th September 2019, banks are mandated to be RTS-compliant and even make APIs available for testing and piloting six months before the market launch. Having the optimal APIs in place that follow best practice principles will be crucial for banks’ “#Beyond PSD2” open banking strategy.

    Have a look at my complete blog and share your views.

    The post How banks should act now to build state-of-the-art APIs for PSD2 and beyond appeared first on Accenture Banking Blog.

    Accenture Banking Blog

     

  • user 3:35 pm on April 3, 2018 Permalink | Reply
    Tags: , compares, , , , , psd2, ,   

    A summary of the new Open API framework in Hong Kong, and how it compares with PSD2 

    Today, #Open Banking is gaining traction globally, through a combination of #banks’ internal efforts, market initiatives, and regulations like the EU’s #PSD2 and the UK’s CMA Open Banking. Now #Hong #Kong has also gotten on board, with the Hong Kong Monetary Authority (HKMA)’s launch of its draft Open API #framework.

    Publication of the framework on January 11, 2018 marked the start of a public consultation that will run until March 15, 2018. Responses will feed into a final version that will be binding for the territory’s largest retail banks, although other banks will be able to join in the future.

    So, what are the highlights of the HKMA’s Open API framework? It includes the following goals:

    • Increase the competitiveness of Hong Kong’s banking sector.
    • Generate opportunities to reach out to untapped markets through better customer experience.
    • Define Open API use cases and deployment timeframes.
    • Recommend Open API technical standards.
    • Recommend Open API facilitation measures.

    One of the most interesting aspects of the HKMA’s framework is the splitting of use cases into four phases with different product categories and timelines:

    Phase 1

    Product and Service Information: Third-Party Providers (TPP)’s access to banks’ products information, which is frequently used by customers on a ‘read-only’ basis and thus helping financial product comparison sites. Banks will be expected to implement these APIs within six months of the framework’s finalization.

    Phase 2

    Customer Acquisition/New Applications: Customer acquisition via TPPs and through online applications for credit cards, loans and some insurance products. Banks will be expected to implement this within twelve months of finalization.

    Phase 3

    Account Information: Retrieval of both stand-alone and aggregated account information. It would help TPP services that aggregate multiple accounts or perform analytics to gain customer insights. The timeline for this phase will be discussed later between HKMA and the banks.

    Phase 4

    Transaction Processing: Enabling TPPs to communicate customers’ payment instructions to banks. Again, the timeline will be discussed later between HKMA and the banks.

    Comparing the HKMA’s framework with the Regulatory Technical Standards (RTS) for strong customer authentication (SCA) under PSD2, one of the biggest differences is that the HKMA’s draft is a mixture of a regulatory paper with some initial timelines, recommendations on specific protocols and data formats, and high-level specifications for each product category. PSD2 is #technology-agnostic and does not define any API standards, with other initiatives like Berlin Group and STET stepping in to fill this gap.

    Other differences between HKMA and PSD2:

    Click to view larger

    While HKMA Open API was inspired by Open Banking and PSD2, its approach is visionary—and in many ways, unique. It remains clear that a single API standard is vital for any economy to attract global innovation and avoid fragmentation. This is a lesson that HKMA is well-placed to take on board.

    Click to view larger
    *6 months (Phase 1) and 12 months (Phase 2) after release of the Open API
    **To be reviewed by HKMA and banks for a Phase 3 and 4 timeline

     

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

     

    The post A summary of the new Open API framework in Hong Kong, and how it compares with PSD2 appeared first on Accenture Banking Blog.

    Accenture Banking Blog

     

  • user 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, #Payments Services Directive II or #PSD2 finally arrived in Europe on Saturday. The #regulation has been dubbed as one of the more substantial regulatory changes of its kind in Europe. While many traditional #banks and FIs might not be thrilled #about having to open their APIs […]
    Bank Innovation

     

  • user 12:19 am on January 13, 2018 Permalink | Reply
    Tags: , , , , psd2,   

    Payments Regulation PSD2 Arrives in Europe 

    EXCLUSIVE – Major European #payments #regulation, #PSD2 is set to go live tomorrow in #Europe. #Banks 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

     

  • user 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 #industry ecosystem through the #Open #Banking regulation. And in the EU, the #PSD2 (Revised Payment Services Directive) regulations—coming into force on 13 January 2018—require #banks 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 (#APIs) 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 #Standards (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 #vital: 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 #fintech 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

     

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

    PSD2: Scoping out the impacts of the RTS 

    The #PSD2 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 #technology-neutral, the EBA banned screen scraping in its final draft, whereas the EC wants to allow it (on a contingency basis).

    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).

    #Banks/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

     

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

    The Geopolitics of PSD2 

    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 #PSD2. You&8217;ve said before that it&8217;s broadly misunderstood. Care to elaborate?

    Sure. #Banks, 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 was originally published in hackingfinance on Medium, where people are continuing the conversation by highlighting and responding to this story.

    Bank Innovation

     

  • user 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 #PSD2, a new era of secure payments has begun in the European Union. The new regulation is aimed at enhanced customer protection against #fraud, with stringent liability and accountability requirements and strong customer authentication features.

    Read the report

    PSD2 requires European #banks 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 #security 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

     

← Older posts

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Close Bitnami banner
Bitnami