Skip to main content
Version: 17

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:

  • TBC

Deprecation notice​

The following features have been deprecated in this major release:

  • Flow step DOSSIER_QUESTIONS is deprecated in favor of the new flow step DOSSIER_QUESTIONNAIRE.
  • Flow steps PARTY_IDENTITY_QUESTIONS, PARTY_QUESTIONS and UBO_QUESTIONS are deprecated in favor of the new flow step PARTY_QUESTIONNAIRE.
  • Flow steps MIFID_V2_KNOWLEDGE_EXPERIENCE, MIFID_V2_FINANCIAL_SITUATION and MIFID_V2_GOALS are deprecated in favor of the new flow steps DOSSIER_QUESTIONNAIRE or PARTY_QUESTIONNAIRE.
  • Action UploadReportToFileServer is deprecated in favor of the new action UploadReportToFileServerV2.

Infrastructure​

Multi-tenancy support​

Next to in-schema multi-tenancy support, where multiple organizations share the same database schema, it is now also possible to set up multi-tenancy with separate database schemas for each organization. This allows for better data isolation between organizations and can be beneficial for larger customers. Compared to fully duplicated deployments, this approach is more cost-efficient while still providing a good level of isolation.

See Multi-tenancy for more information.

Configuration​

Rich text input type​

A new RICH_TEXT input type is available for field definitions and question answer types. This provides a text editor with formatting options such as bold, italic, underline and numbered/bullet lists.

danger

Migration needed!

Rich text editor values are saved with html formatting in the database. This means it is not straightforward to switch between a text-area and the rich text editor. The migration below can be used if you want to switch some_table.some_field from text-area to the editor. The migration encodes <, > and & and replaces new-lines by a proper html <br/>. Remember to migrate the _archive table if relevant.

The final not like '<p>%' is to avoid migrating rows that already contain html. This query can only be executed once! Double execution would lead to a double encoding of & to &amp; to &amp;amp;.

UPDATE some_table
SET some_field = REPLACE(REPLACE(REPLACE(REPLACE(some_field, '&', '&amp;'),'<', '&lt;'),'>', '&gt;'), '\n', '<br/>')
WHERE 
    some_field IS NOT NULL 
  AND 
    (some_field LIKE '%&%' OR some_field LIKE '%<%' OR some_field LIKE '%>%' OR some_field LIKE '%\n%') 
  AND 
    some_field NOT LIKE '<p>%';

FSP Definition: Configurable party type options on FSP level​

A new setting is available on FSP definitions to define which party types are allowed on the FSP. This setting applies everywhere in the application. For example if your FSP never works with indivision parties, then you can configure the other party types in the FSP definition settings and there will be no mention or way to create indivisions on that FSP anymore.

See FSP Definition for more information.

Advice flow field definition driven​

The advice flow is now field-definition driven, meaning that the name of the commercial product and/or suggested back office can be configured (from an autofill list for example).

Flow Definition: Addition of a flow step identifier​

In the flow definition, each flow step now has a unique identifier. This change will not have an impact on existing flow definitions, but it allows the user to create flow definitions with multiple flow steps of the same type within a responsibility.

⚠ī¸ī¸ Defining flow steps of the same type within a responsibility should only be configured when using module DOSSIER_INFORMATION_EXCHANGE.

Flow Definition: UBO step can be configured in the CLIENT responsibility​

The flow definition library has been updated to allow the UBO management step to be configured in the CLIENT responsibility.

Flow Definition: Set custom titles in the sidebar for flow steps​

It is now possible to set a custom title for each flow step that is shown in the sidebar. This is very useful when the default title is either not clear enough for the user, or when it is too long (e.g. the title of a questionnaire).

Additionally it's also possible to set a custom title for the responsibility groupings in the sidebar.

The translation key can be configured in the flow definition, see Flow Definition: BaseFlowStepSettings and Flow Definition: BaseFlowStepSettings for the technical model.

Flow Definition: Set custom titles in the PDF for flow steps​

It is now possible to set a custom title for each flow step that is shown in the PDF generated at the end of the flow.

The translation key can be configured in the flow definition, see Flow Definiition: BaseFlowStepSettings for the technical model.

Flow Definition: New flow step types PARTY_QUESTIONNAIRE & DOSSIER_QUESTIONNAIRE​

New flow step types are now available in the flow definition. These flow steps are similar to the existing questionnaire related flow steps, but can only be linked to 1 specific form section. If multiple sections need to be shown, the flow step can be configured multiple times. This will also improve the user experience, more specifically showing which sections have been filled out and which haven't.

Flow Definition: Multiple signing options configurable​

The SIGN flow step now allows configuring multiple signing options, by using a filter that is applied on the current user. This allows for example to let selected signatories sign with a signing provider, while the rest of the users can simply sign by drawing their signature on the screen.

For more information about signing options, see FSP Definition: Signing types.

Flow Definition: Associated party filter for IDENTITY and CLIENT responsibilities​

It is now possible to configure an associatedPartyFilter on flow steps within the IDENTITY and CLIENT responsibilities, similar to what existed for the ASSOCIATED_PARTIES responsibility. This allows flow steps to be shown selectively based on a party's role in the dossier. For example, party details can be requested only from selected signatories, or the identity step can be skipped for parties that are not owners.

See the flow definition documentation and Associated party data filterfor more information.

Flow Definition: Different field definitions per associated party type​

Field definitions in the flow can now be configured with filters based on a party's associated party type in the dossier. This allows different field visibility, requirement, or read-only rules to apply to different parties of the same base type depending on their role — for example, requiring an additional field only for the client party but not for a dossier relation. When a party holds multiple roles, the applicable field definitions are merged.

See Field definitions per associated party type for more information.

Flow Definition: Configurable "at least one signatory required" validation​

A new validation class FlowSignatoryRequired can now be configured on the signatories flow step. When enabled, the user must select at least one signatory before proceeding to the next step. The validation supports a dossier filter for more fine-grained control over which dossiers require a signatory.

See the validation classes documentation for more information.

Configuration scoped to organization level​

Previously, identifiers for all configuration entities (e.g. dossier definitions, flow definitions, questions, etc.) were required to be unique across the entire instance. Starting in v17, identifiers only need to be unique within the same organization. This enables exporting the configuration of one organization and importing it into another organization on the same instance.

Additionally, the id_organization column is now mandatory (NOT NULL) on the following entities: dossier definition, flow definition, form definition, profile definition, question, and task list definition.

The id_organization column remains nullable for the entities below to support loading default config on startup:

  • flow option definitions
  • report queries
  • lists
  • roles
  • providers

Data export: dossier summary snapshots included in bulk export​

When exporting dossiers, existing dossier summary snapshots are now automatically included. For each snapshot, a PDF is generated and stored alongside the export, and the dossier JSON contains a summarySnapshots field with snapshot metadata and the generated PDF filename reference. Snapshots can be found in the /snapshots subfolder of the dossier export.

See Data Export Scheduled Provider for more information.

Creditsafe V6: UBO enrichment support​

The Creditsafe V6 party provider now supports enrichment with Ultimate Beneficial Owner (UBO) profiles using the Creditsafe Connect company identifier associated with the selected company.

See Creditsafe Party Provider for more information.

Creditsafe V7: search by VAT number​

A new Creditsafe V7 party provider is available. In addition to searching companies by name and company number, it supports searching by VAT number, which is also used when resolving related parties and UBO profiles. When a VAT number is provided it takes precedence and is used as the sole search criterion.

See Creditsafe Party Provider for more information.

Map more Creditsafe credit-report fields to party metadata​

The Creditsafe V7 party provider gains a metadataMappings setting that maps company credit report fields (financials date, global credit limit currency and value, and international credit score) onto party metadata keys you choose. Configure only the fields you need; each is stored under its configured metadata key.

See Creditsafe Party Provider for more information.

Creditsafe V8: additional NACE codes as a list​

A new Creditsafe V8 party provider is available that stores the additional NACE codes as a list instead of the comma-separated string of the earlier versions, so the metadata key you configure for them can be a multi-autocomplete field on a NACE code list. A company without additional codes leaves the metadata key unset; V6 and V7 keep storing the comma-separated string.

See Creditsafe Party Provider for more information.

Creditsafe v9: limit how old the stored equity may be​

By default the Creditsafe party provider stores the equity of the most recent financial statement, however old that statement is. An FSP that only accepts recent figures configures a maximum age in years: the equity is then only stored when the financial year of that statement is at or after the current calendar year minus that number.

See Creditsafe Party Provider for more information.

Creditsafe V10: one place to map the enriched data​

A new Creditsafe V10 party provider is available. It searches and enriches exactly as V9 does, but configures everything it stores on a party in one place: the credit score, fraud risk score, company status, equity, capital, financial statement currency and additional NACE codes move from a setting of their own into the metadataMappings map, alongside the fields that were already configured there.

See Creditsafe Party Provider for more information.

Creditsafe Global Monitoring: rescreen only the companies that changed​

A new Creditsafe monitoring rescreening provider rescreens only the dossiers of companies that Creditsafe reports as changed, instead of every dossier matching the dossier filter on every run. Companies are put under monitoring when their dossier is approved and taken out again when their last dossier is archived, so a scheduled run spends due diligence provider calls only where something actually happened.

This works as one chain: a monitoring provider holding the Creditsafe portfolio, the actions CreditsafeMonitoringRegister and CreditsafeMonitoringDeregister, and the rescreening provider. All of them need to be configured together.

See Creditsafe Monitoring Rescreening Provider for more information.

Configurable privacy & terms of use acceptance checkbox​

The privacy policy and terms of use acceptance checkbox shown at the start of the information exchange flow is now configurable. When no privacy or terms of use settings are configured in the white-label settings, the checkbox is no longer shown and the flow proceeds without it.

See Privacy policy and terms of use for more information.

List conditions can check membership without a filter value​

Conditions using isInList / isNotInList no longer require a listFilterValue. When it is left blank, the condition checks pure list membership: isInList matches when the data point exists as an entry in the list and isNotInList matches when it does not, regardless of any value stored against that entry. This makes plain membership lists (which have no per-entry values) usable directly. Providing a listFilterValue keeps the existing behavior (the matched entry's value must equal it), so existing configurations are unaffected.

See the Condition concept for more information.

An SMS provider per country​

An organization can now configure several SMS providers and have the OTP sent through the one that serves the destination country. Each provider lists the countries it handles in the new SMS_COUNTRIES setting, and the provider that leaves the setting empty handles all remaining countries. Organizations with a single SMS provider keep working unchanged, since a provider without countries serves every destination.

See the SMS providers library for more information.

Send OTP codes through Bird Verify​

The new SMS provider sends and validates OTP codes through Bird's Verify API: platform.bird.com. Bird generates the code, delivers it using its own message template and validates it again when the user enters it, so the code length and the message content are configured at Bird instead of in Harmoney.

See the SMS providers library for the configuration of both, including which one to pick.

Send emails through Mailgun​

A new email provider hands the email to the messages API of Mailgun, both for the standard Harmoney domain and for an organization's own domain: the shared provider sends from the standard domain, a provider configured on the organization from that organization's domain. Mailgun returns an identifier for every email it accepts, which is recorded with the sent email so it can be traced back in the delivery logging of Mailgun afterwards.

The name of the white label can be shown as the sender, and the tracking of Mailgun stays disabled unless it is switched on, so the registration, invitation and verification links in an email are not replaced by links of Mailgun.

See the Mailgun email provider for the configuration.

Export the delivery of Mailgun emails​

A new scheduled provider exports the delivery of the emails Mailgun sent for a domain to a CSV file and uploads it through a file transfer provider.

See the Mailgun delivery export for the configuration and the columns of the file.

Filter dossiers on time spent in their current status​

Dossier filters now accept statusUpdatedRelativeDates, which matches on how long a dossier has been in its current status. Unlike timeUpdatedRelativeDates, other edits to the dossier — a document upload, an assignee change — do not reset that clock, which makes it the criterion to use for chasing and escalation, for example "in CUSTOMER_FOLLOW_UP for more than 7 days". A dossier that never left the status it was created in has no recorded status change and therefore never matches.

See the Dossier filter for all available criteria.

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.

Filter dossiers on the due diligence of their client​

The dossier filter can now select dossiers on the due diligence of their client, matching the screening result and the manual result of a check separately. A dashboard tile can, for example, count the dossiers whose client is a PEP or sanction-listed hit that has not been assessed yet; entering a manual result takes the dossier out of the count.

See the Dashboard module for more information.

New version of the report upload action​

A new action, UploadReportToFileServerV2, uploads a generated report to a file server. Its filename can reuse the name the report was generated with and format the upload timestamp in any date format, on top of the FSP name and report identifier already available. It can also be limited to a list of reports, so only those reach the file server and every other report generated in the FSP, scheduled or from the UI, is skipped. UploadReportToFileServer is deprecated and keeps behaving exactly as before, so moving an FSP over is a change of action class and nothing else: the same filename settings produce the same names.

See the Upload a report to a file server action for more information.

UI/X-updates​

Context switcher​

The context switcher will now display 'My info' when on the profile page.

Dossier Status Transition buttons on Mobile display​

On mobile the Status Transition buttons were displayed as links. Now they are displayed as buttons.

Information exchange filtering and details​

The information exchanges card has been modified to display a more readable name and can now be filtered on the status field. Clicking on the name will take you to newly added 'information exchanges' tab that provides some additional data about the progress of the exchange.

Outreach questionnaire answers on the dossier summary​

The dossier summary can now include a card showing the answers of the outreach questionnaire, based on the same submission snapshot used for the generated PDF. The card lists one row per answering party and can be expanded to a read-only view of the answers. Which form sections are shown (and which specific questions are excluded) is selected in the dossier summary configuration, and the card is also rendered in the dossier summary PDF.

Default value re-applied when conditional trigger fires​

When a field becomes visible again as a result of a conditional trigger, its configured defaultValue is now re-applied. Previously the default value was only applied on initial load, which could leave the field empty or inconsistent when shown again. This ensures a complete and consistent form when fields are toggled by conditions.

RBA & Due Diligence​

Due Diligence parameters in RBA card sorted by score​

Due diligence parameter results displayed in the RBA card are now sorted in a consistent order: parameters with the highest RBA score are shown first, followed by parameters with equal scores sorted alphabetically by name. Parameters without a score (non-score-based RBA configurations) appear last, also sorted alphabetically.

RBA result metadata field​

The RBA result entity now supports a metadata field that allows customer defined fields in the RBA model. The metadata fields are manageable in the application and via the gateway API.

Associated parties due diligence validation V2​

A new version AssociatedPartiesDueDiligenceValidationV2 of the associated parties due diligence validation is available. Compared to V1, it additionally supports requiring a manual assessment when the system result of a parameter matches configured values, reporting a separate error for each parameter requiring a manual assessment.

See the validation documentation for more information.

Manual due diligence check caching​

By default, manually triggered due diligence checks never use cached results. It's now possible to allow due diligence providers to use cached provider results during manual due diligence checks. A new due diligence provider setting DUE_DILIGENCE_RESULT_CACHE_ENABLED allows to enable cached results for each provider individually. This setting applies only for manually triggered DD checks. When enabled on a provider, a cached provider result will be used if possible. This can be useful to limit costly provider calls. Automated checks will continue to always reuse cached results based on expiration rules.

Associated parties CDD check V2: choose which parties are screened​

The new FrontOfficeAssociatedPartiesCddCheckV2 action lets the configuration decide which parties of a dossier are screened. By default it screens the RBA subjects exactly like FrontOfficeAssociatedPartiesCddCheck; with useRbaConfiguration set to false it screens the parties matching an associated-party filter, for example the client only.

See the FrontOfficeAssociatedPartiesCddCheck action.

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.

Information Exchange​

Define multiple flow steps of the same type within a responsibility​

ℹī¸ This feature is only available when using module DOSSIER_INFORMATION_EXCHANGE. It is now possible to define multiple flow steps of the same type within a responsibility.

Some common use cases are:

  • Showing documents multiple times in the flow where each step allows uploading documents of a certain type
  • Configuring multiple identical flow steps, but with different filters on the party

An additional configuration property is also available to prevent identical flow steps from being asked multiple times.
For example when details are requested for all related parties and the counterparty is also one of the related parties, we want to prevent that the details step is shown in 2 places in the flow.

We refer to the flow definition documentation for more information.

After cancellation of an information exchange, the invitation URL will no longer be useful.​

In previous versions, the invitation URL could still be used to enter the information exchange when the information exchange was cancelled and a new one was created. This is no longer the case, the counterparty will need to be invited again to receive a new valid URL.

Information Exchange PDF: answers grouped by flow step type​

In the PDF generated at the end of the flow, answers for flow steps of the same type are now shown together, in the same order as in the flow. This provides a consistent and predictable PDF layout when multiple questionnaire, detail or document steps of the same type are configured within a responsibility.