Skip to main content
Version: 18

Executive summary

warning

Due to our deprecation policy, certain custom implementations may have been removed in this release (see Removal notice). Identify configuration issues using the configuration validation before upgrading.

Removal notice​

The following features will be removed in the next major release:

  • Experimental feature linkedDossiers is being promoted to a supported feature; see Linked dossiers.
  • Dynamic Web Twain integration (DocumentLibraryType.DYNAMIC_WEB_TWAIN)

The following features have been removed in this release:

  • Back-office gateway endpoints
    • /external/v3/back-offices/*
    • /external/v4/back-offices/*

Deprecation notice​

The following features have been deprecated in this major release:

  • Event actions FactFindNeedsAnalysisDocumentRequired, DossierBankAccountDocumentRequired and DossierProofOfAccountHolderRequired are deprecated in favor of the generic DossierDocumentRequired action.
  • Event actions ScheduleInviteCounterpartyReminder and RemindCounterpartyOnInformationExchangeCompletion are deprecated in favor of their V2 counterparts (ScheduleInviteCounterpartyReminderV2 and RemindCounterpartyOnInformationExchangeCompletionV2), which support per-invitation-type filtering and per-reminder-index e-mail templates.
  • FlowStepDossierDocumentsPositiveAssessmentsValidation: document assessment problems on the document flow steps are now reported automatically as part of the flow step completeness (see Document validation messages on the document flow steps). This validation no longer needs to be configured and can be removed.
  • The flow option DIRECT_INVESTOR_SMS, which will be removed in the next major release.

Configuration​

Free choice of dossier type & service​

The dossier type and the dossier service are no longer fixed enumerations. They are free text values now, filled from a configurable autocomplete list. To add your own type or service, declare it on a dossier definition and link that definition to the FSP definition. It is then available in the create and update dossier modal, with a label from the white label translations FRONT_END.VALUE.DOSSIER_TYPE.<value> and FRONT_END.VALUE.DOSSIER_SERVICE.<value>. The product logic that was hardcoded on the old enum values is gone. The INSURED_PERSONS and BENEFICIARY modules no longer depend on the INSURANCE module or type, and a dossier of type INSURANCE does not always have an insurance reference anymore: the insurance data is only created once it actually holds data. The old enum values keep working as strings, so existing dossiers, configuration and integrations are not impacted. Do review what relies on the old closed set, such as reports, data warehouse mappings and code that expects an insurance reference on every INSURANCE dossier. See the migration guide.

See the Dossier definitions for more information.

Support for 28 languages​

The application is now available in 28 languages instead of 7. Bulgarian, Croatian, Czech, Danish, Estonian, Finnish, Greek, Hungarian, Icelandic, Latvian, Lithuanian, Norwegian, Polish, Romanian, Russian, Serbian, Slovak, Slovenian, Swedish, Turkish and Ukrainian are added to English, German, French, Dutch, Spanish, Italian and Portuguese. Translations are provided out of the box for the user interface, e-mails, PDF output, default lists and date formats in each of these languages. A new language only appears in the language picker after it has been activated on the white label.

See the White label details for more information.

Tasks can be disabled on task list definition level​

It is now possible to disable a task on the task list definition level. The task can then no longer be linked to a dossier, but it stays in the system for historical purposes.

RBA assessment: Clear the manual assessment when the RBA rating increases​

By default the manual assessment is cleared when a change is detected in the due diligence information used for the RBA calculation. With the new setting clearManualAssessmentOn in the assessment settings of the RBA module, this can be limited to an increase of the RBA rating, or switched off completely. The setting replaces the existing lockManualAssessment (existing FSP definitions are migrated automatically).

See the RBA Module for more information.

Modules can be configured based on the dossier context​

It is now possible to configure certain modules based on the dossier context. A setting on the module then determines whether the module is enabled or disabled for a specific dossier.

See the Module concept for more information.

Configurable bulk actions on the dossier list​

Administrators can now configure bulk actions on the dossier list. Front-office users select a set of dossiers and apply one of the configured actions: update the status, update a field, or trigger a configured event for follow-up automation. Actions can be restricted to specific roles, and progress is shown live as the action runs through the selection. Next to the bulk action permission, every dossier and every field in the selection is validated against the same card ACLs and field definitions as on the dossier detail page. A field update on the RBA assessment, for example, is checked against the RBA ACL: a user who cannot change the risk assessment on the dossier cannot change it in bulk either. Status updates are checked in the same way.

See the FSP Dossiers Module for more information.

Document validation messages on the document flow steps​

On the document flow steps, all applicable validation messages are now shown together and grouped by severity, instead of only the first one. For example a metadata-driven info message next to a "document required" error. The document assessment is now part of the flow step completeness: a document without a positive assessment blocks the step, a document flagged as a warning does not. This is stricter than before. When assessment is enabled but no positive assessment values are configured, a document counts as not approved yet, where it previously showed as done. The front-end no longer blocks the user in that case, so the back-end enforces it. Document types that are hidden or read-only on the step are not reported.

Task completion details​

Who completed a task and when ("completed by" and "completed on") can now be added to the task card and dossier summary through field definitions. Both are hidden by default.

Linked dossiers​

Linked dossiers (related to a party) can now be seen in a table on a party details page. With this, the experimental linkedDossiers feature becomes a supported feature. To enable it, set linkedDossiersCard.enabled to true in the FspPartiesModuleSettings of the FINANCIAL_SP_PARTIES module. The card is shown based on an ACL driven by that setting, and no longer through the experimental features of the white label.

Disable status management of an identity or the UBO structure​

It is now possible to disable the status management of an identity and of the UBO structure, which means that they will not have a status and will not be included in any status-based logic. When status management is disabled, the status is no longer shown and the approval status transitions (front and back office) do nothing. The validations that require an approved identity or UBO structure no longer block a status transition, a due diligence check or the RBA calculation. Editing is no longer limited to status OPEN either, so the identity and the UBO structure stay editable throughout the dossier. For the identity this also applies to managing its documents. Use the new enableStatuses setting on the IDENTITY and UBO modules to switch this on or off. Status management is only active when the setting is true. Existing FSP definitions are migrated with the setting enabled, so nothing changes for them.

See the Identity Module settings and the UBO Module settings for more information.

Dropdowns and multi-selects can now show a subset of their options in a "Recommended" group at the top of the list, with the other options below in an "All" group. This helps the user to find the most relevant choices quickly, without losing the other options.

  • For fixed option lists, set recommendedOptions on the field definition to the keys of the recommended options.
  • For autocomplete (endpoint) lists, mark the list elements with recommendedOption instead.

The grouping is only applied when at least one recommended option is configured. Otherwise the list stays flat, as before.

More context in the configuration validation​

The configuration validation now also reports the action, event or provider a problem belongs to, and not only the constraint that was violated. A missing required action setting, for example, can now be found without having to look in the database.

Data point placeholders on the summary / information page​

Placeholders such as {{ clientName }}, {{ partyName }} and {{ dossierName }} only worked in the title of the flow step. They are now also applied in the card titles and in the text content of the DOSSIER_SUMMARY flow step. This way a summary or information page can address the client and the dossier by name.

See the Summary / Information for more information.

Default currency list for the transaction card​

A default autocomplete list with EUR, USD and GBP is now provided out of the box. A custom field definition with a currency list is no longer needed to start using the transaction card.

Callback type is free text​

The type setting of the TriggerCallbackEvent and TriggerCallbackEventV2 actions is no longer a fixed enumeration and accepts any string. Customers with a gateway integration can use this to pass their own callback type to their internal processes. The values that are configured today keep working.

See the Callback actions for more information.

Autocomplete for questionnaire sections in the settings editor​

The settings editor now proposes the section identifiers of all form definitions of the organization for the sections setting of the DOSSIER_QUESTIONNAIRE and PARTY_QUESTIONNAIRE flow steps, and for coveredBy. This works the same way as the autocompletion that already exists for the provider identifiers.

See the Form definitions for more information.

Readable status transition diagram for complex workflows​

A dropdown on the dossier status transition diagram allows to choose which elements (actions, validations, ...) are drawn. This keeps a workflow with a lot of transitions readable, without having to zoom out in the browser.

See the Status transitions for more information.

Separate lists for system and manual assessment​

The assessment value shown on the dossier now takes its translation from the system assessment list as well as from the manual assessment list. A separate list can therefore be defined for each of them. Previously the manual values had to be duplicated in the system list to avoid that the key was displayed.

See the RBA Module for more information.

When the OneTrust integration is active on a white label (otDomainId) and the marketing footer is enabled (hasBrandingFooter), the footer now also shows the OneTrust cookie settings link. A visitor can use it to reopen the consent manager from any page.

See the OneTrust integration for more information.

ADMIN role mapping through SSO​

SSO_ROLE_MAPPING now also supports the administrator role, so administrators no longer have to be assigned manually per instance. When an SSO login only returns the admin role, the roles the user already has on an FSP are kept. Identity providers that return nested or complex attribute values for the roles claim are supported as well. Cloudflare Access, for example, wraps name, id and email in child elements of the groups value, which used to fail with "No roles could be matched".

See the SSO providers for more information.

FinScan sanctions and PEP screening​

A new due-diligence provider screens individuals and companies against the FinScan ISI service. Each match FinScan returns is resolved into the CDD parameters the FSP has mapped to it, taking both the sanctions category and the PEP category of the matched watchlist record into account — so a sanctioned politically exposed person is recorded as both, rather than as only one of the two. A SCREENING_HIT parameter separately records whether anything matched at all, which distinguishes a party that was never screened from one that was screened and came back clean. A branded PDF screening report is attached to the dossier when document fetching is enabled, with one page per match listing the category, dates of birth, nationalities and aliases an analyst needs to rule a false positive in or out.

See the FinScan provider for more information.

Screen a party's phone number and email for fraud risk​

A new Trustfull due diligence provider screens an individual's mobile phone number and email address for fraud signals, and reports each as its own due diligence parameter with its own PDF report on the party. You choose which of the two checks run and the fraud score above which a parameter is flagged.

This provider is experimental and is only available once ALLOW_EXPERIMENTAL_CUSTOM_CLASSES is enabled for the organization.

See the Trustfull provider for the configuration.

Scheduled CSV import of daily delta files, with result file​

The scheduled CSV import can now pick up files whose name changes with every delivery, such as a daily file with a date in its name. This is switched on with a new setting; the matching files are then imported one after the other, oldest first. Existing configurations keep working unchanged. See the CSV Import Scheduled Provider for more information.

UI/X-updates​

Party details drawer​

Party details can now be opened in a drawer, so users can review party information without leaving the dossier they are working in.

Autosave for flow data​

Flow data and the dossier questionnaires are now saved automatically as the user fills them in, so work is no longer lost before an explicit submit. A message at the top of the form and an indicator next to the "Save and next" button show whether the data has been saved. When an autosave fails, this is reported to the user and the save is retried on the next change. Autosave does not mark the step complete or enforce mandatory fields: those checks still apply on submit.

Modern interactive network graph​

The network visualization on the dossier and on the party has been replaced by a new, full-size graph that can be dragged, zoomed and panned. Each entity type has its own color, so companies and individuals are easy to tell apart. The previous graph became cramped with complex corporate structures (directors, shareholders, subsidiaries, UBOs). Those now stay readable.

Bulk document download​

Documents can now be downloaded in bulk as a ZIP file, instead of one by one. On a dossier or party document card, one action downloads all documents of the card. It is also possible to first select the documents and to download only that selection. When all documents are selected, the button switches back to the download-all action, so there is always only one download button.

Show or hide expired documents by default​

It is now possible to configure on the FSP side whether documents with a validUntil date in the past are shown by default, as was already the case in the outreach. The new filterByValidUntil setting is available on the PARTY_DOCUMENTS and DOSSIER_DOCUMENTS modules, and on the IDENTITY module under its documents settings. It defaults to true, which hides the expired documents as before. The user can still show or hide them with the filter on the card.

See the Modules for more information.

Context switcher separated from the user profile​

The context switcher and the profile link are now two separate elements in the top navigation. Previously the switcher always showed the user name, which did not change when the context did. The navigation now shows the active context, and the user name stays visible next to it.

Toggles on the signatories flow step​

The signatories flow step now uses toggles instead of checkboxes, and the "must sign" column has a label. This makes it clearer what is being set for each signatory.

Metadata support in the list tables​

Filtering on the tables now uses the field definitions, which makes it possible to filter on metadata fields. The list is also filtered immediately, instead of having to submit the query every time. On the dossier and party overviews, metadata fields can also be added as a column and sorted on, ascending and descending. Note that the search box at the top of the list does not search in metadata: a metadata value is found through the filter form. The available metadata follows the field definitions of the organization. Conditional field definitions cannot be used in these tables. Filters that could previously only be reached by drilling down from the dashboard are now available in the filter form as well.

Information Exchange​

Motivation of the advice remains​

The motivation of the advice is now stored on the dossier, and no longer only on the submission group. It is therefore kept when a new information exchange is created, and it is also available when the dossier is picked up again outside the information exchange. Only the last motivation is kept. A data migration copies the most recent existing motivation to the dossier, so nothing has to be entered again.

Inspecting the information exchange as FSP user​

ℹī¸ This feature is only available when using module DOSSIER_INFORMATION_EXCHANGE. By configuring a new flow option of type INSPECT, FSP users can now inspect the information exchange of a dossier, and update certain data.

This is useful to prepare or review data before the counterparty is invited, or to guide a counterparty who has questions about the information exchange.

The data that is being reviewed is often still incomplete on purpose. The inspect flow does not block on this: the FSP user sees the completeness errors, but can still continue to the next flow step with a separate button. With "Save and next" the completeness check and the form validation would stop the user.

Role Based Access Control (RBAC)​

Card-level RBAC on the front-office cards​

Access to the front-office cards is now based on RBAC permissions and ACLs, and no longer on the legacy role checks. In this release this is done for the dossier and dossier detail card (including the create, update, delete and import actions on the dossier), the dossier list, the party list, the individual identity card, and the dossier and party document cards. On the document cards, the document assessments have their own rights, separate from the rights on the document itself. For a role that is configured correctly nothing changes: data is only returned to users who are allowed to see it, and the create, update and delete buttons are only shown to users who are allowed to use them.

See Access control for more information.

Restricting a list to a subset through a role filter​

A filter can be added to the permission of a role, to limit that role to a subset of the dossier or party list. Conditions on metadata fields are supported as well. A user then only sees the dossiers or parties within that subset. To keep these filters manageable, the settings editor does not propose every field of the entity, but only the ones that make sense as a permanent access limit on role level: dossier statuses, lifecycles, types, party types, dossier services, RBA ratings and assessments, time windows and metadata.

Owner and assignee with custom roles​

A user no longer needs one specific legacy role to be set as owner or assignee of a dossier. Every user with a role on the FSP can be selected. This keeps the behavior predictable when custom roles are used.

Identity status transitions accept non-legacy roles​

Identity status transitions can now also be linked to custom roles, and no longer only to the legacy roles. Removing a role takes these links into account. Users without a legacy role can therefore perform identity status transitions.

Gateway​

The Gateway API changes of this release (gateway version 4.6) are described in the Gateway release notes: information exchanges through the Gateway API, triggering an automation for a dossier, setting the owner and assignee of a dossier, the task completion timestamp, and multiple flow completion results per dossier.