Skip to main content
Version: 🚧 Next

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 have been removed in this major release:

  • Due diligence providers:
    • AppcDueDiligenceProvider
    • AppcGoogleV2DueDiligenceProvider
    • AppcGoogleV3DueDiligenceProvider
    • AppcGoogleV4DueDiligenceProvider
    • AppcPanamaV2DueDiligenceProvider
    • CreditsafeDueDiligenceProvider
    • DowJonesDueDiligenceProvider
    • DowJonesV2DueDiligenceProvider
    • EverialDueDiligenceProvider
    • EverialV2DueDiligenceProvider
    • ForcesV2DueDiligenceProvider
    • HarmoneyDataDueDiligenceProvider
    • LexisNexisDataPlusDueDiligenceProvider
    • WorldCheckDueDiligenceProvider
  • Document providers:
    • BankersAlmanacDocumentProvider
    • CreditsafeCompanyDocumentProvider
    • CreditsafeCompanyProfileDocumentProvider
    • EverialDocumentAssessmentProvider
    • KYCRegistryCompanyV3DocumentProvider
  • Party providers:
    • BankersAlmanacPartyProvider
    • CreditsafeV3PartyProvider
    • KYCRegistryV3PartyProvider
  • Rescreening and scheduled providers:
    • AppcRescreeningProvider
    • InformationRequestScheduledProvider
    • ReportGenerationScheduledProvider
  • SSO providers:
    • AzureSSOProvider
  • Conditional section classes:
    • SectionVisibleWhenClientCompanySelfEmployed
    • SectionVisibleWhenCompanyCharity
    • SectionVisibleWhenCompanyClub
    • SectionVisibleWhenCompanyClubV2
    • SectionVisibleWhenCompanyCOOP
    • SectionVisibleWhenCompanyGeneral
    • SectionVisibleWhenCompanyGeneralV2
    • SectionVisibleWhenCompanyOther
    • SectionVisibleWhenCompanyPartnership
    • SectionVisibleWhenFatcaIsNOK
    • SectionVisibleWhenFatcaOKAmldNOK
    • SectionVisibleWhenNameContainsHarmoney
    • SectionVisibleWhenProductCorpFoundTrust
    • SectionVisibleWhenProductCorpFund
    • SectionVisibleWhenProductCorpFundFound
    • SectionVisibleWhenProductCorpFundSOW
    • SectionVisibleWhenProductCorporate
    • SectionVisibleWhenProductFoundation
    • SectionVisibleWhenProductFoundationSOW
    • SectionVisibleWhenProductFund
    • SectionVisibleWhenProductTrust
    • SectionVisibleWhenProductTrustSOW
    • SectionVisibleWhenUBOTypeOther
    • SectionVisibleWhenUBOTypeOwnership
    • SectionVisibleWhenUBOTypeSeniorManagingOfficial
    • WhenClientCompanyNotSelfEmployed
  • Dossier status transition validations:
    • AssociatedPartiesValid
    • AssociatedPartiesValidation
    • DossierFieldsValidation

Deprecation notice​

The following features have been deprecated in this major release:

  • InformationRequestV2ScheduledProvider and InformationRequestV3ScheduledProvider, superseded by InformationRequestV4ScheduledProvider, which also supports module DOSSIER_INFORMATION_EXCHANGE. V4 has the same settings and CSV columns as V3.
  • The action PerformClientOutreach is superseded by PerformClientOutreachV2.
  • The action ScheduleInviteCounterpartyReminderV2, superseded by ScheduleInviteCounterpartyReminderV3
  • The action RemindCounterpartyOnInformationExchangeCompletionV2, superseded by RemindCounterpartyOnInformationExchangeCompletionV3
  • The action InformReminderSentV2, superseded by InformReminderSentV3

Configuration​

Reminder mails for information exchanges towards an individual​

Reminder mails now also work for information exchanges run through the DOSSIER_INFORMATION_EXCHANGE module. Until now the reminder actions looked the counterparty up on the dossier's responsibility matrix, which only exists in the INVESTOR_FLOW module, so an information exchange towards an individual was never reminded - silently, without an error.

The three reminder actions have a V3 that identifies the counterparty the way the new module does and works under both modules: ScheduleInviteCounterpartyReminderV3, RemindCounterpartyOnInformationExchangeCompletionV3 and InformReminderSentV3. The settings are unchanged, so moving an existing configuration over is a matter of changing the class name. Which mail a counterparty receives is unchanged as well.

See Reminder mails for more information.

Additional contact details on a party​

A party can now hold extra e-mail addresses, phone numbers and addresses next to its main data, through the new PARTY_CONTACT_INFO module.

See the Modules for more information.

Multi-level structures in the information exchange​

The flow can now capture a structure of any depth, such as the related parties and owners of a related company of the client, with the new associationScope of the associated party filter. The PARTY_RELATED_PARTIES and UBO flow steps are available in the ASSOCIATED_PARTY responsibility, and a counterparty gets the flow steps of a party when it manages the association that introduces it; existing configurations keep their behaviour.

See Capturing multi-level structures and the association scope for the configuration.

Optional confirmation on status transitions​

An FSP can now let dossier status transitions run without the confirmation modal, saving a click per transition; only a required status comment keeps the modal. By default the confirmation stays in place.

See the Dossiers module for the configuration.

Metadata fields on tasks​

The tasks of a dossier now support metadata fields, the same way the dossier and party models already did. Once the fields are defined in the field-definition provider, they are shown on the tasks card when the FSP user expands a task, they can be filled in when the user edits the task, they are stored on the task itself, and they are available on the API Gateway. All existing field types are supported, and field-level interdependencies work as elsewhere: a metadata field can be shown or hidden, and made required or optional, based on the value of another field on the task.

The tasks card is only shown when the TASKS module is activated, and without configured metadata fields nothing changes on it. Task metadata is not available in the PDF documents, in the flow, or through the CSV import.

See the Tasks library for more information, the Field definition provider for the entities that support metadata fields, and the Modules for the TASKS module.

Summary snapshot PDFs in the file-server export​

Every dossier summary snapshot now gets a PDF render per white-label language, produced right after the snapshot is taken. The new DOSSIER_SUMMARY_SNAPSHOTS include of UploadDossierToFileServer (module DOSSIER_SUMMARY, gateway version V4) lists the snapshots with a signed link per stored render, keyed by language; the same include is available on the Gateway API dossier GET. The off-boarding export (ExportData) now reuses the stored renders. Snapshots taken before this release have no renders and are listed without links.

See also Upload a dossier to a file server .

Restyle a flow with design tokens​

A flow can now be restyled to follow a customer's own branding, without code changes. The flow definition settings accept design tokens - colours, type sizes and dimensions of fields, cards, buttons, options and messages - and a font that override the white label's styling while that flow is open, together with two layout switches: hiding the step sidebar and placing the previous button above the page heading. The white label settings accept the same kind of tokens for styling that until now could not be configured; they apply everywhere except the admin.

Without design tokens nothing changes, so existing configurations need no migration.

See the Flow definitions for more information.

UI/X-updates​

Split view follows the responsibility​

The flow's source document preview now offers the documents of the responsibility the active step belongs to, instead of only the dossier's documents. A party's identity step previews that party's documents, and a responsibility without document steps shows no panel.

See the Split view documentation for the configuration.

Information Exchange​

[title]​

[description]

Create information exchanges through CSV import​

The new import template HARMONEY_DOSSIER_COUNTERPARTIES_IMPORT creates an information exchange on a dossier for an individual or intermediary counterparty, one per row, identified by the external references of the dossier and the counterparty. The information exchange is created but not yet initiated, so it can be completed afterwards from the dossier page or by the configured automated actions. A row for a counterparty that already has a pending or completed information exchange on the dossier is skipped, and a pending information exchange of another counterparty is replaced without executing the actions linked to the status change. Front offices moving from INVESTOR_FLOW to DOSSIER_INFORMATION_EXCHANGE use this template where they used the responsible-parties import before.

See CSV import for the template.

Automated client outreach for information exchanges​

The new action PerformClientOutreachV2 invites the counterparties of a dossier automatically, with the INVESTOR_FLOW module as well as with the DOSSIER_INFORMATION_EXCHANGE module. With DOSSIER_INFORMATION_EXCHANGE it invites the individual counterparties of the information exchange that was already created on the dossier. Front offices moving from INVESTOR_FLOW to DOSSIER_INFORMATION_EXCHANGE replace PerformClientOutreach by this action; the settings stay the same.

See PerformClientOutreachV2 for the configuration.

Role Based Access Control (RBAC)​

Parties controlled by permissions​

The party list, the party details and the party import are now controlled by the permissions of a role, through the new details and set namespaces under party. The default roles keep the access they had, except that observers can no longer create or change parties. The dataExport scope moved from party to party.set. A party that is still in use by a dossier or another party is no longer offered for deletion. See Permissions for more information.

Gateway​

Additional contact details of a party​

A party now carries a contactInformation list holding its additional e-mail addresses, phone numbers and addresses, available from API v4 when the PARTY_CONTACT_INFO module is enabled. Add the PARTY_CONTACT_INFO include to receive it on a GET. On create and update the list follows the updateStrategy: with OVERWRITE (the default) entries that are no longer present are removed and an empty list clears them all, with APPEND existing entries are kept. Leaving the field out keeps the existing contact details untouched.

Summary snapshots of a dossier​

The dossier GET can now return the summary snapshots of the dossier through the new DOSSIER_SUMMARY_SNAPSHOTS include (also part of expanded=true), for FSPs with the DOSSIER_SUMMARY module. Each snapshot carries a pdfs map with a signed link per stored PDF render, keyed by the 2-letter ISO language code. The map only lists the renders that are stored, so it may be partial or empty.

Task metadata​

The tasks of a dossier now carry a metadata object holding the metadata fields of the task. Existing integrations are unaffected: both the read and the write direction require the TASKS module to be activated for the FSP.

See the Gateway release notes for the details.​

Data Warehouse​

[title]​

[description]