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

Document created by RSA Product Team Employee on Jun 21, 2020Last modified by RSA Product Team Employee on Jun 22, 2020
Version 3Show Document
  • View in full screen mode

Summary:

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

What's New in This Release

New enhancements to support PSD2 compliance in Adaptive Authentication

These enhancements have been made to support PSD2 compliance when creating rules in the Policy Management application:

Note: For more information on the entire process, see the PSD2 Compliance appendix in the Back Office User Guide.

  • isSca API data element is now supported to be sent in an authenticate or notify message as opposed to an analyze message: The isSca data element, which indicates whether the Authentication Method being used is defined as a Strong Customer Authentication (SCA), is now supported to be sent in the Open API using an authenticateRequest or notifyRequest message. It is no longer supported to send this data element in an analyzeRequest message. For more information on the isSca data element, see authenticateRequest Message and notifyRequest Message in the API Reference Guide. In addition, see PSD2 Data Elements in the Back Office User Guide.
  • New support for differentiating between PSD2 transaction payments and regular transaction payments in the API SOAPs and Policy Management application:
    • New parameter called transactionTypeOthers added to handle all PSD2 related transaction payment types in the transactionData structure: A new parameter called transactionTypeOthers has been added to the transactionData structure in the API. This value determines the different transaction payment types, which are related to creating PSD2 compliant rules. The available values in the transactionTypeOthers parameter were removed from the transferMediumType parameter, so that it would be easy to differentiate between PSD2 transaction payments and regular transaction payments in the API. For more information, see transactionTypeOthers in the API Reference Guide.
    • New rule condition (fact) called Transaction Type Others added to handle all PSD2 related transaction types in the Policy Management application: A new rule condition (fact) called Transaction Type Others has been added to the Transaction Details rule condition (fact) category in the Policy Management application. The values listed in this new Transaction Type Others rule condition should be used to create PSD2 compliant rules and were removed from the Transaction Type rule condition, where the values were previously listed. As a result, when creating rules that comply with PSD2 exemptions in articles 11-16, ensure that you use these value as listed in the Transaction Type Others rule condition. For more information, see Transaction Details Rule Conditions (Facts) in the Back Office User Guide.
  • New rule conditions (facts) added to meet PSD2 exemptions in article 10 when creating rules in the Policy Management application: To comply with all PSD2 exemptions in article 10 when creating rules in the Policy Management application, these rule conditions (facts) have now been added to the Account Details rule condition (fact) category:
    • User First SCA Was Successful (Direct Access): Indicates whether the first ever attempt by a user to access their account by passing the Strong Customer Authentication (SCA) was successful. The default value is False. For PSD2 compliance with Article 10, use the SESSION_SIGNIN and VIEW_STATEMENT event types.
    • User First SCA Was Successful (3rd Party): Indicates whether the first ever attempt of a third party to access a user's account using a Strong Customer Authentication (SCA) was successful. The default value is False. For PSD2 compliance with Article 10, use the SESSION_SIGNIN and VIEW_STATEMENT event types.
      Note: This parameter is initiated independently for each of the third party services.

      For more information, see Account Details Rule Conditions (Facts) and Create Article 10 Compliant Rules in the Back Office User Guide.

  • New rule conditions (facts) changes to meet PSD2 exemptions in article 11 when creating rules in the Policy Management application: To comply with all PSD2 exemptions in article 11, additional changes have been made to the rule conditions (facts) used when creating rules in the Policy Management application. When creating rules for contactless payments as explained in article 11, there are now two ways to configure these rules. You can either set up these rules for the payments performed by a specific 3rd party service or any 3rd party service. You must select one of these approaches and use the corresponding rule conditions (facts) in the Account Details rule conditions (facts) category. For more information on these rule conditions (facts), see Account Details Rule Conditions (Facts) and Create Article 11 Compliant Rules in the Back Office User Guide.
    • New rule conditions (facts) added for creating rules where the payments are performed by any 3rd party service: These rule conditions (facts) have now been added to the Account Details rule condition (fact) category. Use these rules when you want to configure that the payments are performed by any 3rd party service:
      • # of Contactless Payments Made by Any 3rd Party Service from User Account Since Last Successful SCA: The number of payments without a contact that were performed from the user's account by any 3rd party service, since the last successful authentication with a Strong Customer Authentication (SCA). This rule condition is available for all event types, but for PSD2 compliance with Article 11 use the PAYMENT event type.
      • Total Amount of Contactless Payments Made by Any 3rd Party Service 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 any 3rd party service, since the last successful authentication with a Strong Customer Authentication (SCA). This rule condition is available for all event types, but for PSD2 compliance with Article 11 use the PAYMENT event type.
    • Updated rule conditions (facts) names for creating rules where the payments are performed by a specific 3rd party service: These rule conditions (facts) names in the Account Details rule condition (fact) category have been updated, so the name matches closer to the description. Use these rules when you want to configure that the payments are performed by a specific 3rd party service.
Old Rule Condition (Fact) NameNew Rule Condition (Fact) Name
# of Contactless Payments Made from User Account Since Last Successful SCA# of Contactless Payments Made by a Specific 3rd Party Service from User Account Since Last Successful SCA
Total Amount of Contactless Payments Made from User Account Since Last Successful SCATotal Amount of Contactless Payments Made by a Specific 3rd Party Service from User Account Since Last Successful SCA

New rule conditions (facts) called Cookie Risk Score and Flash Risk Score added to the RSA eFraudNetwork rule condition (fact) category in the Policy Management application

When creating rules in the Policy Management application, these two new rule conditions (facts) are now available in the RSA eFraudNetwork rule condtion (fact) category:

  • Cookie Risk Score: The risk score of a cookie detected as fraudulent, as received from the RSA eFraudNetwork service. The possible values are: 800, 900, 920, 950, 970, and 1000.
  • Flash Risk Score: The risk score of a flash cookie detected as fraudulent, as received from the RSA eFraudNetwork service. The possible values are: 800, 900, 920, 950, 970, and 1000.

For more information, see the RSA eFraudNetwork Rule Conditions (Facts) section in the Back Office User Guide.

 

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