Regulatory Technical Standard (RTS) for PSD2 SCA in Plain Text

Abbreviations Used with PSD2

  1. Payment Services Directive 2 - PSD2 
  2. Regulatory Technical Standard (RTS) - A recommendation requested by PSD2 as a technical guideline to be compliant with PSD2 
  3. Strong Customer Authentication - SCA 
  4. Payment Service User - PSU 
  5. Account Servicing Payment Service Provider (ASPSP) - the existing banks
  6. Payment Initiation Service Provider (PISP) - a third party entity or a bank itself that can initiate the payment process 
  7. Account Information Service Provider (AISP) - a third party or a bank itself which can retrieve PSU's account information may be to show an aggregate view of all accounts. 
  8. Payment Service Providers issuing card- based payment instruments (PSP) - payment service providers that existed in pre PSD2 era who are doing payments through card networks like VISA or Mastercard. Sometime this is also used to refer all PSPs including PISP and AISP.
  9. Common and Secure Communication (CSC) 
  10. Third Party Payment Service Providers (TPP)
  11. Access to accounts - XS2A
When addressing PISPs, AISPs and PSPs as a whole we will use XSPs here in this post.

PSD2 Flow in Brief

With PSD2 we get rid of going through the card network to perform a payment and directly calls the relevant banks APIs that exposed in secured manner.

RTS in Plain Text

CHAPTER 1 - GENERAL PROVISIONS

Article 1 - Subject matter

Strong Customer Authentication - At PSU authentication XSPs should be applying at least 2 factors from below.
  • Knowledge - Something we know, like our user name and password.
  • Possession - Something we have, like a mobile or some other device.
  • Inherence - Something we are, like our biometric identities including iris pattern, finger print etc.
More details on this comes later.
- Freedom is present to exempt SCA, based on the level of risk, the amount and the recurrence of the payment transaction and of the payment channel used for its execution.
- Confidentiality and the integrity of the PSU’s personalised security credentials - Encrypt user credentials at LDAP, MYSQL like data layer level, in transport and mask at displaying.
- CSC between XSPs (HTTPS protocol needs to be used in communication.)

Article 2 - General authentication requirements

    • Transaction monitoring mechanisms that enable PSPs to detect unauthorised or fraudulent payment transactions. - This needs analytical capabilities integrated within an authorization server, so that it govern the PSU's sessions with the feedbacks received from monitoring systems.
    • Transaction monitoring mechanisms takes into account, at a minimum, each of the following risk-based factors:
      • lists of compromised or stolen authentication elements
      • the amount of each payment transaction
      • known fraud scenarios in the provision of payment services
      • signs of malware infection in any sessions of the authentication procedure
    • When exempt application of SCA following should be considered at minimum on a real time basis.
      • the previous spending patterns of the individual PSU.
      • the payment transaction history of each of the PSP’s PSU 
      • the location of the payer and of the payee at the time of the payment transaction provided that the access device or the software is provided by the PSP.
      • the abnormal behavioral payment patterns of the PSU in relation to the payment transaction history.
      • In case the access device or the software is provided by the PSP, a log of the use of the access device or the software provided to the PSU and the abnormal use of the access device or the software.

    Article 3 - Review of the security measures

    PSPs that make use of the exemption under Article 16(below) shall perform the audit for the methodology, the model and the reported fraud rates at a minimum on a yearly basis.

    CHAPTER 2 - SECURITY MEASURES FOR THE APPLICATION OF STRONG CUSTOMER AUTHENTICATION

    Article 4 - Authentication code

    • Authentication based on two or more elements categorized as knowledge, possession and inherence shall result in the generation of an authentication code. - Use of Multi Factor Authentication(MFA)
    • The authentication code shall be accepted only once by the PSP when the payer uses the authentication code to access its payment account online, to initiate an electronic payment transaction or to carry out any action through a remote channel which may imply a risk of payment fraud or other abuses.- If it is OAuth 2.0 standard authorization code that comes into mind at this level, yes.
    1. no information on any of the elements of the strong customer authentication categorized as knowledge, possession and inherence can be derived from the disclosure of the authentication code
    2. it is not possible to generate a new authentication code based on the knowledge of any other authentication code previously generated
    3. the authentication code cannot be forged.
      The number of failed authentication attempts that can take place consecutively, within a given period of time shall be temporarily or permanently blocked, shall in no event exceed five times. - Account locking capabilities should be present in the solution.
      The payer should be alerted before the block is permanent. Where the block is permanent, a secure procedure shall be established allowing the payer to regain use of the blocked electronic payment instruments. (May be send an email to user at account lock.)

      The communication sessions are protected against the capture of authentication data transmitted during the authentication and against manipulation--> HTTPS

      A maximum time without activity by the payer after being authenticated for accessing its payment account online shall not exceed five minutes. (Session timeout 5 minutes)
       

    Article 5 - Dynamic linking

    When SCA is applied, additionally following security requirements should be met.
    • the payer is made aware of the amount of the payment transaction and of the payee.
    • Authentication code generated shall be specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction. Any change to those will invalidate the generated authentication (so authentication code only applicable to PISP flow.) Adopt security measures which ensure the confidentiality, authenticity and integrity of each of the following, (we may need encryption and signing of the relevant data. A JWT token which carries this data between services can cater for this)
    • the amount of the transaction and the payee through all phase of authentication.
    • the information displayed to the payer through all phases of authentication including generation, transmission and use of the authentication code.
    in relation to payment transactions for which the payer has given consent to execute a batch of remote electronic payment transactions to one or several payees, the authentication code shall be specific to the total amount of the batch of payment transactions and to the specified payees.

    Article 6 - Requirements of the elements categorised as knowledge Payment

    Elements of SCA categorised as knowledge shall be subject to mitigation measures in order to prevent their disclosure to unauthorised parties.
    (Keeping passwords encrypted, OTPs and other two factor data sending through secured channels.)

    Article 7 - Requirements of the elements categorised as possession

    Elements categorized as possession shall be subject to measures designed to prevent replication of the elements.

    Article 8 - Article Requirements of devices and software linked to elements categorised as inherence

    Elements categorized as inherence shall be subject to measures ensuring that the devices and the software guarantee resistance against unauthorised use of the elements through access to the devices and the software.

    Article 9 - Independence of the elements Payment

    Measures in terms of technology, algorithms and parameters, which ensure that the breach of one of the elements does not compromise the reliability of the other elements.

    Mitigating measures shall include each of the following,
    • the use of separated secure execution environments through the software installed inside the multi-purpose device;
    • mechanisms to ensure that the software or device has not been altered by the payer or by a third party or mechanisms to mitigate the consequences of such alteration where this has taken place
    (Mostly relevant with the third party applications like mobile apps or other devices that capture fingerprint like factors. So we have concerns if the two factors are fingerprint and SMS OTP while an application installed in mobile is used for fingerprint scan.)

    CHAPTER 3 - EXEMPTIONS FROM STRONG CUSTOMER AUTHENTICATION

    SCA applicability should be able to be handled dynamically under different policies that may need to be configurable. As these policies may change by the time. Hence a dynamic policy configuration mechanism should be applicable on deciding the authentication flow for the user.

    Article 10 - Payment account information IS

    • PSPs are exempted from the application of SCA where a PSU is limited to accessing either or both of the following items online without disclosure of sensitive payment data,
      • the balance of one or more designated payment accounts
      • the payment transactions executed in the last 90 days through one or more designated payment accounts.
    Exemption is not applicable in below scenarios,
    • the payment service user is accessing online the information for the first time;
    • the last time the payment service user accessed the online information and strong customer authentication was applied more than 90 days ago.

    Article 11 - Contactless payments at point of sale

    PSPs are exempted from the application of SCA where the payer initiates a contactless electronic payment transaction provided that both the following conditions are met:
    • the individual amount of the contactless electronic payment transaction does not exceed EUR 50
    • the cumulative amount, or the number, of previous contactless electronic payment transactions initiated via the payment instrument offering a contactless functionality since the last application of strong customer authentication does not, respectively, exceed EUR 150 or 5 consecutive individual payment transactions.

    Article 12 - Transport and parking fares

    SCA exempted when payer initiates an electronic payment transaction at an unattended payment terminal for the purpose of paying a transport or parking fare.

    Article 13 - Trusted beneficiaries and recurring transactions

    SCA exempted when,
    • the payee is included in a list of trusted beneficiaries previously created or confirmed by the payer through its account servicing payment service provider
    • the payer initiates a series of payment transactions with the same amount and the same payee.
    Those not exempted if payer creates, confirms or subsequently amends, the list of trusted beneficiaries after consent is given or the payer initiates the series of payment transactions for the first time, or subsequently amends, the series of payments.

    Article 14 - Payments to self

    Exempted from SCA.

    Article 15 - Low-value transaction

    SCA exempted when,
    • the amount of the remote electronic payment transaction does not exceed EUR 30
    • the cumulative amount, or the number, of previous remote electronic payment transactions initiated by the payer since the last application of strong customer authentication does not, respectively, exceed EUR 100 or 5 consecutive individual remote electronic payment transactions.

    Article 16 - Transaction risk analysis

    Analytics , Fraud detection

    Calculation of fraud rate needs to be handled using a fraud detection solution.

    Detailed risk scoring enabling the payment service provider to assess the level of risk of the payment transaction.

    Article 17 - Monitoring

    An analytics solution is needed here.
    When exemptions are in action,
    Need to publish information when decision is made on applying SCA or not in the flow. This will need the help of an API management solution along with Identity and Access Mgt capabilities.
    • PSPs shall record and monitor the following data for each payment instrument, with a breakdown for remote and non-remote payment transactions, at least on a quarterly basis (90 days):
    • the total value of all payment transactions and the resulting fraud rate, including a breakdown of payment transactions initiated through strong customer authentication and under the exemptions.
    • the average transaction value, including a breakdown of payment transactions initiated through strong customer authentication and under the exemptions
    • the number of payment transactions where any of the exemptions was applied and their percentage in respect of the total number of payment transactions

    Article 18 - Invalidation and optionality of exemptions

    When their monitored fraud rate exceeds for two consecutive quarters (180 days), PSPs can cease transactions to be exempted by SCA.

    Providing evidence of restoration of compliance of their monitored fraud rate with the applicable reference fraud rate, PSPs can again start exemption of SCA.

    CHAPTER 4 - CONFIDENTIALITY AND INTEGRITY OF THE PAYMENT SERVICE USERS’ PERSONALISED SECURITY CREDENTIALS

    Article 19 - General requirements

    • Confidentiality and integrity of the personalised security credentials of the PSU, including authentication codes, during all phases of authentication including display, transmission and storage.  (Use of password fields in the UI, store sensitive data after encryption, secured transport layer)
    • personalised security credentials are masked when displayed and not readable in their full extent when input by the PSU during the authentication (Mask password field etc.)
    • personalised security credentials in data format, as well as cryptographic materials related to the encryption of the personalised security credentials are not stored in Plaintext. (Keystores also need to be encrypted. User passwords encryption.)
    • secret cryptographic material is protected from unauthorised disclosure. (Protection of keystore, guaranteed with system level security.)

    Fully document the process related to the management of cryptographic material used to encrypt or otherwise render unreadable the personalised security credentials. (Handling key expiration, replacements of people administrating the system.)
    Ensure that the processing and routing of personalised security credentials and of the authentication codes generated, take place in secure environments in accordance with strong and widely recognised industry standards. (HTTPS)

    Article 20 - Creation and transmission of credentials

    • ensure that the creation of personalised security credentials is performed in a secure environment.
    • mitigate the risks of unauthorised use of the personalised security credentials and of the authentication devices and software due to their loss, theft or copying before their delivery to the payer.

    Article 21 - Association with the payment service user

    Ensure that only the payment service user is associated with the personalised security credentials, with the authentication devices and the software in a secure manner.

    The premises of association may be, not limited to the payment service provider’s premises, the internet environment provided by the payment service provider or in other similar secure websites and its automated teller machine services.

    The association via a remote channel of the PSU’s identity with the personalised security credentials and with authentication devices or software shall be performed using SCA. (This implies that SCA even in AISP flow)

    Article 22 - Delivery of credentials, authentication devices and software

    The delivery of personalised security credentials, authentication devices and software to the payment service user is carried out in a secure manner designed to address the risks related to their unauthorised use due to their loss, theft or copying.

    Mechanisms that allow the payment service provider to verify the authenticity of the authentication software delivered to the payment services user via the internet. (Some signature comparison mechanism when sent over email??)

    The delivered personalised security credentials, authentication devices or software require activation before usage; (Lock the account until activation done over the phone?? Should have a portal for call center staff members to do these??)

    Article 23 - Renewal of personalised security credentials

    Ensure that the renewal or re-activation of personalised security credentials follows the procedures of creation, association and delivery of the credentials and of the authentication devices in accordance.

    Article 24 - Destruction, deactivation and revocation

    Secure destruction, deactivation or revocation of the personalised security credentials and devices and software.

    Deactivation or revocation of information related to personalised security credentials stored in the PSP’s systems and databases and, where relevant, in public repositories. (Should we totally delete or keep them marked as revoked? So according to GDPR spec, if the PSU request a forget of the data, we should delete it.)

    CHAPTER 5 - COMMON AND SECURE OPEN STANDARDS OF COMMUNICATION

    Article 25 - Requirements for identification

    Ensure secure identification when communicating between the payer’s device and the payee’s acceptance devices for electronic payments, including but not limited to payment terminals.

    risks against misdirection of communication to unauthorised parties in mobile applications and other payment services users’ interfaces offering electronic payment services are effectively mitigated.
    (Mutual SSL between the parities is an option. Else we can depend on the PKI and use signatures and encryption to secure the data placed in a JWT sent in a header)

    Article 26 - Traceability

    Have processes in place which ensure that all payment transactions and other interactions with all the parties are traceable in all stages.

    PSPs shall ensure that any communication session established with the PSU, other PSPs and other entities,including merchants, relies on each of the following,
    • a unique identifier of the session (JSESSIONID for the session can serve this)
    • Security mechanisms for the detailed logging of the transaction, including transaction number, timestamps and all relevant transaction data
    • timestamps which shall be based on a unified time-reference system and which shall be synchronised according to an official time signal.

    Article 27 - Communication interface

    • ASPSP have in place at least one interface which meets each of the following requirements,
      • Any Payament Service Provider can identify themselves towards the ASPSP. (API to register themselves. TPP on-boarding, may be need to make use of workflows for human interactions to receive approval upon back ground check.)
      • AISPs can communicate securely to request and receive information on one or more designated payment accounts and associated payment transactions.
      • PISPs can communicate securely to initiate a payment order from the payer’s payment account and receive information on the initiation and the execution of payment transactions.
      • ASPSPs can create separate APIs for above or expose the ones used for their own PSUs.
    For the purposes of authentication of the PSU, the interfaces shall allow account information service providers and payment initiation service providers to rely on the authentication procedures provided by the ASPSP to the PSU. In particular the interface shall meet all of the following requirements: (An identity provider's Federation Capabilities are required here.)

    For the purposes of authentication of the PSU, the interfaces of ASPSP shall allow AISPs and PISPs to rely on the authentication procedures provided by the ASPSP to the PSU. In particular the interface shall meet all of the following requirements,
    • a PISP or an AISP shall be able to instruct the ASPSP to start the authentication.
    • communication sessions between the ASPSP, the AISP, the PISP and the PSU shall be established and maintained throughout the authentication.
    • The integrity and confidentiality of the personalised security credentials and of authentication codes transmitted by or through the PISP or the AISP shall be ensured. (Making use of SAML, OIDC like protocols with signing and encryption enabled.)
    • ASPSP shall ensure that their interface(s) follows standards of communication which are issued by international or European standardisation organisations (Swagger 2.0). ASPSPs shall make the summary of the documentation publicly available on their website at no charge.
    • Except for emergency situations, any change to the technical specification of their interface is made available to authorised XSPs in advance as soon as possible and not less than 3 months before the change is implemented. (API versioning capabilities can help)
    • ASPSPs shall make available a testing facility, including support, for connection and functional testing by authorised XSPs that have applied for the relevant authorisation, to test their software and applications used for offering a payment service to users. No sensitive information shall be shared through the testing facility. (API Mgt solutions sandbox endpoints exposed as secured APIs.)

    Article 28 - Obligations for dedicated interface

    (Need extensive monitoring on API mgt nodes regarding their performance factors such response time. High availability deployment requirements are there.)
    • When dedicated interfaces are provided for XSPs than what is exposed to PSUs, ensure that the dedicated interface offers the same level of availability and performance, including support, as well as the same level of contingency measures, as the interface made available to the PSU for directly accessing its payment account online.
    • In case of failure to achieve above, ‘without undue delay and shall take any action that may be necessary to avoid its reoccurrence’. PSPs can report such cases to competent authorities too.
    • ASPSPs shall also ensure that the dedicated interface uses ISO 20022 elements, components or approved message definitions, for financial messaging. (something to consider when defining APIs. Their requests and response should adhere to the standard)
    • Communication plans to inform PSPs making use of the dedicated interface in case of breakdown, measures to bring the system back to business as usual and a description of alternative options PSPs may make use of during the unplanned downtime.

    Article 29 - Certificates

    (electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC) eIDAS ANNNEX III & IV

    According to the references, need support for following signing algorithms to be aligned with this specification. ‘XAdES, PAdES, CAdES or ASiC Baseline Profile’ which are to cater for different LOAs(Level of Assurance). In such case need to make use of extensions available and customize the signing procedures or implement the capabilities into the products.

    Qualified certificates for electronic seals or for website authentication shall include in English additional specific attributes in relation to each of the following:

    The name of the competent authorities where the payment service provider is registered. The role of the PSP, which maybe one or more of the following:
    • ASPSP
    • PISP
    • AISP
    • PSP issuing card-based payment instruments
    Addition of above attributes shall not affect the interoperability and recognition of qualified certificates for electronic seals or website authentication.

    Article 30 - Security of communication session

    When exchanging data via the internet, secure encryption is applied between the communicating parties throughout the respective communication session in order to safeguard the confidentiality and the integrity of the data, using strong and widely recognised encryption techniques. (HTTPS)

    XSPs shall keep the access sessions offered by ASPSP as short as possible and they shall actively terminate the session with the relevant account servicing payment service provider as soon as the requested action has been completed. (Federated session at IDP should be killed upon completion of task.)

    When maintaining parallel network sessions, avoid possibility of misrouting between XSPs.

    XSPs with ASPSP, contain unambiguous reference to each of the following items:
    • the PSUs and the corresponding communication session in order to distinguish several requests from the same PSUs
    • for payment initiation services, the uniquely identified payment transaction initiated
    • for confirmation on the availability of funds, the uniquely identified request related to the amount necessary for the execution of the card-based payment transaction.

    Article 31 - Data exchanges

    ASPSP should comply with,

    API Manager should - guarantee same information goes out for direct access by PSU or AISP/PISP
    • Details submitted to AISP should be same as given to PSU without sensitive data.
    • Immediately after receipt of the payment order, PISPs with the same information on the initiation and execution of the payment transaction provided or made available to the PSU when the transaction is initiated directly by the latter.
    • Immediately provide PSPs with a confirmation whether the amount necessary for the execution of a payment transaction is available on the payment account of the payer. This confirmation shall consist of a simple ‘yes’ or ‘no’ answer.
    Error sequence handling (API Manager error sequences needs to be defined).

    AISP can request information from ASPSP in either of following cases,
    • Whenever the PSU is actively requesting such information.
    • Where the PSU is not actively requesting such information, no more than four times in a 24 hour period, unless a higher frequency is agreed between the AISP and the ASPSP, with the PSU’s consent. (API Manager throttling policy needs to be customized or configured to handle this)

    CHAPTER 6 - FINAL PROVISIONS

    Article 32 - Review

    May propose updates to the fraud rates

    Article 33 - Entry into force This

    Regulation applies after 18 months after entry into force date.

    Popular posts from this blog

    Signing SOAP Messages - Generation of Enveloped XML Signatures

    Image
    Digital signing is a widely used mechanism to make digital contents authentic. By producing a digital signature for some content, we can let another party capable of validating that content. It can provide a guarantee that, is not altered after we signed it, with this validation. With this sample I am to share how to generate the a signature for SOAP envelope. But of course this is valid for any other content signing as well. Here, I will sign The SOAP envelope itself An attachment  Place the signature inside SOAP header  With the placement of signature inside the SOAP header which is also signed by the signature, this becomes a demonstration of enveloped signature. I am using Apache Santuario library for signing. Following is the code segment I used. I have shared the complete sample here to to be downloaded . public static void main(String unused[]) throws Exception {         String keystoreType = "JKS";         Stri...
    Read more

    Tomcat JDBC Pool - Connection Leak - Catch the Culprit

    Database connection leaks are something that can stay hidden unless paid specific attention and would come to the surface at the most critical stages at a peak time of the system. We would manually check if all the open connections have been closed properly. Then we have various code quality plugins that would scan and check for that. Still when the connections are passed through a complex structure of program both of these can miss a possible connection leak. Then at unit test or integration test levels, we can have checks to validate the counts in the connection pool to avoid this unfortunate situation, that would keep engineers busy at year-end, black Friday, etc. :) In the unfortunate case of hitting with a performance degrade or a total crash of the system which can be propagated via a JDBC connection leak, when we suspect a connection leak, how easily and quickly isolate the culprit. In the Tomcat connection pool, we can do this using 3 properties. removeAbandoned If a...
    Read more

    How to convert WSDL to Java

    Image
    Background Basically WSDL (Web Services Development Language) is an XML document used to describe or locate web services. WSDL stands for Web Services Description Language. The document describes a Web service. It specifies the location of the service and the operations that can be taken.  WSDL2Java is distributed with Axis2 package of Apache and need to set-up Axis2 to use this service. A  guide to set-up Axis2  can be found in apache organization documents .WSDL 2.0 is the currently using version. Obviously JDK should be properly installed too. Note: For the 3rd method you are not needed to set these things by yourself. The WSDL document includes server Java programs for Web services and generated classes using WSDL2Java feature includes client stubs, server skeletons and data types that can help in writing client side. The generated stub classes play a great role in distributed computing and if you are interested can read on  what are...
    Read more