With the launch of release 3.1.0, we have expanded the contract edition options available to better suit the needs of different customer segments. In addition to the two modes available in release 3.0.0 (Advanced and Standard), a new contract edition mode is now offered:

In this release, we expanded the support for multiple product types for all segments and all application areas. Previously, it was only possible to create contracts with different product types for Individuals and Corporate contracts.

Resources throughout the application referring to “accounts” have been updated to reflect this new reality, mentioning now a broader resource: “Products”.

With this update, we have introduced support for multiple product types in transactions. For transactions that are configured to use different product types, users can now select multiple product types in the product selectors rather than just chequing accounts.

The components of the product selectors were updated to support multiple product types.

This update is also reflected in the product filters available across the IB and MB applications. Note that for product selectors, the user customisation regarding product visibility is considered, and only the products marked as visible are displayed. The user customisation is overridden in the filters, and all products the user can access are shown.

This update introduces an improvement to the Customise product groups feature (previously Customise account groups), which is exclusive to Corporate groups. Users can define and organise product groups to simplify access to frequently used products, with the flexibility to include products of different types within a single group. For example, a product group can now include chequing accounts, term deposits, and credit cards, provided they are part of the contract.

The products added to a group will be displayed across the applications as before, but now the applications show the products type that are relevant for each transaction, ensuring a consistent organisation across product lists and product selectors. For example, on a transfer between my accounts (that only supports the product type chequing accounts) in a group that includes both chequing accounts and credit cards, only the chequing accounts will be visible.

The contract rules related to limits, permissions, and signature rules can now be set for other product types and not only for chequing accounts.

Users can set a specific limit for a withdrawal transaction that is associated with the term deposits product type.

This improvement affects the definition of limits and signature rules at the contract level, and limits, permissions and signature rules at the permission group level.

When creating or editing a contract in the BFO/CC, if a product of another type is related to a chequing account, it can only be added to the contract if the chequing account is also included in the contract. For example, if a credit card is related to a chequing account, the chequing account must be in the contract so you can add the credit card. However, limits and permissions are individually set. This means that even if both products are on the contract, you can set different permissions and limits for each of them.

FIs now have the option to require their users to define a PIN in the MB application or not by deciding whether the PIN is mandatory. This setting is defined in the Orchestrator API and is set to true by default, meaning that Android and iOS users will be required to define a PIN.

Option to change the username of the authenticated client and of the delegates with access to the authenticated contract in the BFO/CC. Trustees must be authenticated to their individual contract to change their username. The old username will deactivated once a new one is defined.

In addition, all username changes in the BFO/CC trigger a notification. By default, this notification is configured as mandatory, but this can be changed in the EMS.

Authentication Server now limits the maximum of attempts for password recovery. FIs can define the number of attempts allowed. An attempt is considered when, for an existing username, the attempt is unsuccessful (username and contacts do not match and the process was not completed) or successful (username and contacts match and the process was completed).

The setting to configure the number of attempts (MaxNumberAttempts) is defined in the appsettings file in the User API. By default it is enabled, and the maximum number of attempts is set to three.

Once the maximum number of attempts to recover the password is reached, the process is blocked. This can be unlocked in the BFO/CC where a password credential option has been added to reset the number of password recovery attempts.

The number of attempts is associated with a username, and the corresponding user can be notified about this process.

Users will now receive notifications for every password recovery attempt. By default, this notification is configured as mandatory, but this can be changed in the EMS.

Users will now receive a notification when the limit of password recovery attempts is reached, and the process is blocked. By default, this notification is configured as mandatory, but this can be changed in the EMS.

Take more control of your notifications with a new database setting that allows to define which notification types are available for subscription by each customer segment. FIs can decide which segments can subscribe to Account notifications (product-related notifications) and Global notifications (business, security, transactional and generic).