Migrating from Investor Flow to Information Exchange

The modules INVESTOR_FLOW and DOSSIER_INFORMATION_EXCHANGE both let an FSP request information from a counterparty of a dossier (see Concepts - Information Exchange). INVESTOR_FLOW is the older module: the counterparty is a responsible of the dossier, appointed in the responsibility matrix. DOSSIER_INFORMATION_EXCHANGE replaces it: the counterparty is selected when the information exchange is created, and it can be an intermediary FSP as well as an individual. New information exchange functionality is only added to DOSSIER_INFORMATION_EXCHANGE.

This page lists what changes when an FSP moves from the one module to the other, and how the integrations that appoint the counterparty of a dossier are adapted.

What changes

Concept	Module INVESTOR_FLOW	Module DOSSIER_INFORMATION_EXCHANGE
Counterparty	A responsible party of the dossier, appointed in the responsibility matrix.	A counterparty selected when the information exchange is created on the dossier.
Counterparty types	Individual.	Individual and intermediary FSP (the latter requires the INTERMEDIARY module).
Responsibilities	Divided over one or more responsibles, see Responsibility cardinality.	One counterparty completes the whole information exchange; the responsibility cardinality does not apply.
Flow definition	No restrictions.	See Limitations for Individual and Limitations for Intermediary.
Associated party filter	responsibles	counterpartyIndividuals, see Associated party data filter.
Module settings	enabledWhen, securityCheck, showProfile	The same settings with the same meaning, plus migrateGatewayResponsiblesToInformationExchanges (see API Gateway).
Reminder mails	The reminder actions in their V1 or V2 version.	The same three actions in their V3 version; the V2 versions find no counterparty and silently send nothing, see Reminder mails.
Appointing the counterparty via CSV	Template HARMONEY_DOSSIER_RESPONSIBLE_PARTIES_IMPORT (adds a responsible).	Template HARMONEY_DOSSIER_COUNTERPARTIES_IMPORT (creates the information exchange), see CSV import.
Automated client outreach	Action PerformClientOutreach (invites the responsibles).	Action PerformClientOutreachV2 (invites the counterparties of the existing information exchange), see Automated client outreach.
Appointing the counterparty via the API Gateway	POST Flow for a responsible.	The Information Exchanges services.
Exporting invitation URLs or codes	InformationRequestV2ScheduledProvider / InformationRequestV3ScheduledProvider (invites the responsibles).	InformationRequestV4ScheduledProvider (invites the counterparty of the existing information exchange), see Information Request Scheduled Provider.

Steps

1. Check the flow definitions used by the dossier definitions of the FSP against the limitations of DOSSIER_INFORMATION_EXCHANGE, and validate if a migration is possible.
2. Replace the module INVESTOR_FLOW by DOSSIER_INFORMATION_EXCHANGE in the FSP definition. The settings enabledWhen, securityCheck and showProfile keep their meaning and can be copied, see Information Exchange - Configuration.
3. Perform a data migration if necessary, see below.
4. Adapt the integrations that appoint the counterparty of a dossier, see below.

Data migration

This step is only necessary when you want to create information exchanges for dossiers where there was already a responsible available, but the information exchange wasn't initiated (no invitation / url generation).

Be aware that this is only applicable for dossiers that have exactly one responsible defined!

• Configure the provider DossierMigrationProvider
  • specify a dossier filter to select the dossiers you want to migrate (we advice to filter on the dossier statuses e.g. OPEN)
  • specify an AUTOMATION_IDENTIFIER of your choice (e.g. INFORMATION_EXCHANGE_MIGRATION)
  • specify the ID's of the FSP's where you want to migrate dossiers SUPPORTED_FSP (Comma separated list of DB ID's)
  • specify SYSTEM_USER which will be linked to the actions necessary for the migration
• Configure the action InvestorFlowToInformationExchangeMigrationAction linked to the same event type that is configured for the provider above (e.g. INFORMATION_EXCHANGE_MIGRATION)
• Trigger the provider manually on the organization (admin UI)

Integrations

Information Exchange Card configuration

Issue: The message "Information exchange is not applicable" appears even when an exchange is active. This happens if the flow configuration is restricted to INTERMEDIARY while responsibles were defined (and are now translated).

Solution: Update the flow configuration by adding INDIVIDUAL to the applicableCounterpartyTypes. This ensures the card recognizes the counterparty and displays the information exchange correctly.

RBA impact

Update the module settings for 'RBA' if you want the counterparty to be taken into account for RBA calculations: configure type COUNTERPARTY_INDIVIDUAL (if applicable). If customers have a code based configuration, this configuration might also need to be adapted first.

Actions & Validations

• Remove the validation AtLeastOneResponsible from the dossier status transitions (in most cases this is not necessary for the workflow)
• Review the configuration that refers to responsibles: associated party data filters using responsibles (now counterpartyIndividuals)

Automated client outreach

FSPs that invite the counterparty automatically with the action PerformClientOutreach switch to PerformClientOutreachV2. PerformClientOutreach only invites responsibles, so with DOSSIER_INFORMATION_EXCHANGE it invites nobody. The settings of both actions are identical:

1. While the FSP still uses INVESTOR_FLOW, replace the className eu.myharmoney.app.bll.executors.events.PerformClientOutreach by eu.myharmoney.app.bll.executors.events.ie.PerformClientOutreachV2. The behaviour stays the same.
2. Switch the module to DOSSIER_INFORMATION_EXCHANGE. The action then invites the individual counterparties of the current information exchange.
3. Make sure the information exchange is created (from the dossier page, through the API Gateway or by CSV import) before the event that triggers the action is fired. The action does not create the information exchange, and fails when there is none.

Reminder mails

An FSP that sends reminder mails switches the three reminder actions to their V3 version. The V1 and V2 actions look the counterparty up in the responsibility matrix, which no longer holds the counterparty after the migration, so they stop sending reminders for an individual counterparty - without an error.

Event	Replace	By
DOSSIER_COUNTERPARTY_INVITED	ScheduleInviteCounterpartyReminder or ...V2	ScheduleInviteCounterpartyReminderV3
DOSSIER_INFORMATION_EXCHANGE_COMPLETION_REMINDER	RemindCounterpartyOnInformationExchangeCompletion or ...V2	RemindCounterpartyOnInformationExchangeCompletionV3
DOSSIER_INFORMATION_EXCHANGE_COMPLETION_REMINDER_SENT	InformReminderSent or ...V2	InformReminderSentV3

Points of attention:

• Coming from V2, the settings are unchanged: copy them over as they are, only the class name changes. Coming from V1, the settings have to be rewritten, since V1 has no invitationType and configures the reminders as plain values instead of objects.
• Disable the V1 and V2 actions on those same three events. All versions listen on the same events, so leaving them enabled next to the V3 ones sends every reminder twice.
• Keep one action instance per invitationType. An invitation type without a configured action gets no reminder.
• Which mail a counterparty receives does not change.
• The V3 actions only remind a counterparty that still has flow steps to complete, where V2 reminded as long as the information exchange was open. A signatory that already signed, or an intermediary that filled in everything but did not submit yet, is no longer reminded.

API Gateway

Integrations that create a responsible on the dossier through the API Gateway and then call POST Flow should move to the Information Exchanges services, which create, initiate and cancel an information exchange for a counterparty.

However, it will temporarily be possible to use the existing API endporints to create an information exchange of type INDIVIDUAL for a responsible to facilitate migration from existing customers. To enable this functionality, set the following property in the DOSSIER_INFORMATION_EXCHANGE module settings of your FSP definition:

{
  "migrateGatewayResponsiblesToInformationExchanges": true
}

When this boolean is enabled and the Gateway creates/updates a dossier, the system follows this logic based on the number of responsibles found:

Number of Responsibles	Action
0	Any existing pending information exchange is cancelled.
1	• If no existing pending information exchange exists: A new information exchange is created for the responsible. • If an existing pending information exchange exists for this person: Nothing changes. • If an existing pending information exchange exists for another individual: The existing one is cancelled and a new one is created for the current responsible.
> 1	This is not supported. The system will throw an exception.

Creating information exchanges through CSV import

FSPs that appointed the counterparty of a dossier with the CSV template HARMONEY_DOSSIER_RESPONSIBLE_PARTIES_IMPORT switch to the template HARMONEY_DOSSIER_COUNTERPARTIES_IMPORT. It creates an information exchange on a dossier for a counterparty, one per row, and is available on the dossier import page of the front office and as IMPORT_TEMPLATE of the CSV Import Scheduled Provider.

Column	Required	Value
dossier_reference	yes	The external reference of the dossier.
counterparty_reference	yes	The external reference of the counterparty: the external party reference of an individual, or the external reference of an intermediary FSP.
counterparty_type	no	INDIVIDUAL (default when the column or the value is absent) or INTERMEDIARY (requires the INTERMEDIARY module).

A file for individual counterparties is thus the responsible-parties file with the column responsible_party_reference renamed to counterparty_reference. The general file format, the other templates and the result file are described in CSV import.

Exporting invitation URLs with the Information Request Scheduled Provider

FSPs that periodically export invitation URLs or codes to a CSV file with InformationRequestV2ScheduledProvider or InformationRequestV3ScheduledProvider switch to InformationRequestV4ScheduledProvider. V2 and V3 only invite the responsibles of a dossier, so on DOSSIER_INFORMATION_EXCHANGE they export every dossier without an invitation URL.

• V4 has the same settings and CSV columns as V3: changing the implementation class of the provider configuration is enough. A V2 configuration additionally needs the COLUMNS setting.
• V4 invites the counterparty individual of the current information exchange of the dossier. That information exchange must be created first, e.g. with the CSV import or the API Gateway.
• V4 never creates, recreates or cancels an information exchange. An information exchange in a final state (e.g. COMPLETED), or a dossier without an information exchange, is exported without an invitation URL.

See Information Request Scheduled Provider.