RSA Announces the Release of RSA Adaptive Authentication (Cloud) 14.1

Document created by RSA Product Team Employee on Nov 28, 2019Last modified by RSA Product Team Employee on Dec 3, 2019
Version 6Show Document
  • View in full screen mode

Summary:

We are happy to announce the release of RSA Adaptive Authentication (Cloud) 14.1, which includes these new features, enhancements, and changes.

What's New in This Release

New feature support for PSD2 Exemptions to SCA:

Adaptive Authentication (Cloud) 14.1 now includes support for second Payment Services Directive (PSD2) exemptions to Strong Customer Authentication (SCA), which are for payments and account access use cases. To support these changes, additional rules can be created in the Policy Management application that address all PSD2 exemptions in articles 10-16, and PSD2 data elements were added to the to the analyzeRequest message. For more information, see the new PSD2 Compliance appendix in the Back Office User Guide.

This feature enables creating these types of rules in the Policy Management application:

  • Rules to determine the number of days that have passed since the last time the user or 3rd Party Service accessed the user's account after successfully passing the Strong Customer Authentication (SCA) to determine whether a user needs to step up authentication to meet PSD2 requirements. These rules help to comply with PSD2 Article 10 regulation requirements. As a result, these rule conditions (facts) have now been added to these rule condition (fact) categories:
    • Account Details:
      • # of Days Since Last Successful SCA (Direct Access): The number of days since the last time the user accessed their account after successfully passing the Strong Customer Authentication (SCA). This is relevant for SESSION_SIGNIN and VIEW_STATEMENT event types.
      • # of Days Since Last Successful SCA (3rd Party): The number of days since the last time a third party accessed a user's account after successfully passing the Strong Customer Authentication (SCA). This is relevant for SESSION_SIGNIN and VIEW_STATEMENT event types.
        For more information, see Account Details Rule Conditions (Facts) in the Back Office User Guide.
    • Transaction Detail:
      • 3rd Party Name: The name of the third party that is accessing a user's account on behalf of the customer. For more information, see Transaction Detail Rule Conditions (Facts) in the Back Office User Guide.

Note: When creating rules using these rule conditions, the rules should be based on one of these event types: SESSION_SIGNIN or VIEW_STATEMENT.

  • Rules to indicate and challenge whether the amount of payments without a contact, such as payments through Apple Pay and Android Pay, that were performed using a customer's account but without any identity are exceeding the number according to the PSD2 regulations, to understand if a user needs to increase authentication to meet the PSD2 Article 11 requirements. As a result, these rule conditions have been added to these rule condition categories:
    • Account Details:
      • # of Contactless Payments Made from User Account Since Last Successful SCA: The number of payments without a contact that were performed from the user's account by a 3rd party service, since the last successful authentication with a Strong Customer Authentication (SCA).
      • Total Amount of Contactless Payments Made from User Account Since Last Successful SCA: The accumulated payment amount in Euros for the payments without a contact that were performed from the user's account by a 3rd party service, since the last successful authentication with a Strong Customer Authentication (SCA).
        Note: These rule conditions are available for all event types, but are only triggered when the ADD_PAYEE, EDIT_PAYEE, or PAYMENT event types are defined.
        For more information, see Account Details Rule Conditions (Facts) in the Back Office User Guide.
    • Transaction Detail:
      • Transaction Amount (Euro): The specific transaction amount converted to Euros.
      • The Transaction Type now includes a CONTACTLESS_PAYMENT option in the drop-down list.

For more information, see Transaction Detail Rule Conditions (Facts) in the Back Office User Guide.

Note: When creating rules using these rule conditions, the rules should be based on one of these event types: ADD_PAYEE, EDIT_PAYEE, or PAYMENT.

  • Rules based on whether a payment transaction was made by an unattended transport terminal according to the PSD2 Article 12 regulation requirements. As a result, when creating a rule based on the Transaction Detail rule conditions (facts) category, the Transaction Type now includes an UNATTENDED_TRANSPORT_TERMINAL option in the drop-down list. For more information, see Transaction Detail Rule Conditions (Facts) in the Back Office User Guide.
    Note: When creating rules using this rule condition, the rules should be based on this event type: PAYMENT.
  • Rules indicating whether a transaction was made by a Trusted Beneficiary from a Trusted Beneficiaries list, or if this list was added. In addition, to be able to Allow/Challenge the Transaction according to the PSD2 Article 13 requirements to ensure the changes were made by an authenticated user. As a result, when creating a rule based on the Transaction Detail rule conditions (facts) category, the Transaction Type now includes these options in the drop-down list:
    • TRUSTED_BENEFICIARIES_ADD
    • TRUSTED_BENEFICIARIES_EDIT
    • TRUSTED_BENEFICIARIES_PAYMENT

Note:

  • These rules should be based on one of these event types: ADD_PAYEE, EDIT_PAYEE, or PAYMENT.
  • Since these rules are not based on the Policy Management list, the customer is required to manage these lists on their end, and provide the event information to RSA using the API.

For more information, see Transaction Detail Rule Conditions (Facts) in the Back Office User Guide.

  • Rules based on whether a transaction is a recurring payment transaction or a recurring payment list was updated to know if the changes were made by an authenticated user, according to PSD2 Article 14 regulation requirements. As a result, when creating a rule based on the Transaction Detail rule conditions (facts) category, the Transaction Type now includes these options in the drop-down list:
    • RECURRING_TRANSACTION_ADD
    • RECURRING_TRANSACTION_EDIT
    • RECURRING_TRANSACTION_PAYMENT

For more information, see Transaction Detail Rule Conditions (Facts) in the Back Office User Guide.

Note: When creating rules using these rule conditions, these rule should be based on one of these event types: ADD_PAYEE, EDIT_PAYEE, or PAYMENT.

  • Rules based on whether a payment transaction was made between accounts held by the same natural or legal person, to allow the transfer according the PSD2 Article 15 regulation requirements. As a result, when creating a rule based on the Transaction Detail rule conditions (facts) category, the Transaction Type now includes a ME_TO_ME_PAYMENT option in the drop-down list. For more information, see Transaction Detail Rule Conditions (Facts) in the Back Office User Guide.
    Note: These rules should be based on one of these event types: ADD_PAYEE, EDIT_PAYEE, or PAYMENT.
  • Rules indicating whether the payment transaction is a low-value transaction (remote electronic payment) type, and to handle these type of transactions according to the PSD2 Article 16 regulation requirements. As a result, these rule conditions (facts) have now been added to the Transaction Detail rule conditions (facts) category:
    • # of Electronic Payments Since Last Successful SCA: The number of electronic payments that the user performed from their account, since the last successful authentication using a Strong Customer Authentication (SCA).
    • Total Amount of Electronic Payments Since Last Successful SCA: The accumulated payment amount in Euros for the electronic payments that the user performed from their account, since the last successful authentication using a Strong Customer Authentication (SCA).
    • Transaction Amount (Euro): The specific transaction amount converted to Euros.
    • The Transaction Type now includes a REMOTE_ELECTRONIC_PAYMENT option in the drop-down list.

Note: When creating rules using these rule conditions, the rules should be based on one of these event types: ADD_PAYEE, EDIT_PAYEE, or PAYMENT.

For more information, see Transaction Detail Rule Conditions (Facts) in the Back Office User Guide.

To support the Open API, these data elements were added to the analyzeRequest message:

  • isComingFromAggregator: Indicates whether the transaction data sent to the bank from a third party is being collected by an aggregator.
  • isSca*: Indicates whether the Authentication Method being used is defined as a Strong Customer Authentication (SCA).
  • thirdPartyId*: Indicates the ID of the third party carrying out a transaction.
  • thirdPartyName*: Indicates the name of the third party carrying out a transaction.
  • tokenId: Indicates the token ID.

Note: Only the data elements with an asterisk beside them are relevant for PSD2 support.

For more information on these data elements, see analyzeRequest Message in the API Reference Guide.

Risk Engine enhancements:

The RSA Risk Engine has been improved and includes an updated risk model in silent mode, which will be gradually deployed to active mode in 2020 after undergoing testing to improve the risk model before the model is released.

New support for creating rules in the Policy Management application:

When creating rules in the Policy Management application, it is now possible to create rules based on these new items:

  • IP Ground - Speed: It is now possible to create rules based on the "IP Ground -Speed" to identify whether an IP moved too fast since performing various activities, which can be suspected as fraudulent. To enable this, in the IP Details rule conditions (facts) category, these new rule conditions have been added:
    • # Kilometers IP Moved in the Past Day: The distance in Kilometers the IP moved in the past day.
    • # Kilometers IP Moved in the Past Hour: The distance in Kilometers the IP moved in the past hour.
      Note: These rule conditions are only displayed when the channel indicator is set to MOBILE or WEB.
      For more information about these rule conditions, see IP Details Rule Conditions (Facts) in the Back Office User Guide.
  • Payee's routing code lists: It is now possible to create rules based on the payee's routing codes to be able to build the financial institution's policy according to trusted and non-trusted routing codes to better handle end-user transactions. This is performed using the Payee Routing Code rule condition (fact), which was added to the Payee Details rule conditions (facts) category. For more information, see Payee Detail Rule Conditions (Facts) in the Back Office User Guide.

New Risk Score column added to the User Activity History window in the Customer Service application:

The User Activity History window in the Customer Service application now includes a Risk Score column that indicates the risk score that this activity received from the RSA Risk Engine. For more information, see User Activity History in the Back Office User Guide.

Documentation updated look and feel:

The Adaptive Authentication (Cloud) 14.1 documentation set has been updated to align with the RSA rebranding efforts to provide an updated look and feel. The documentation includes a number of formatting changes, such as a new cover page with a unique image for the Adaptive Authentication (Cloud) product, updated fonts, and new colors.

 

For additional documentation, downloads, and more, visit the RSA Adaptive Authentication page on RSA Link.

 

EOPS Policy:

RSA has a defined End of Primary Support policy associated with all major versions. Please refer to the Product Version Life Cycle for additional details.

Attachments

    Outcomes