20 posts tagged with "ETL"

Agency Bulk Upload no longer requires a Managed Relationship file. Where customers don't hold Managed Relationship data, the Managed Relationship data type can be de-selected on the Agency ETL task, and the system will find or create the Managed Relationship between the Investment Manager and each Underlying Principal during Load. A new Autoname MRs setting gives those Managed Relationships a meaningful name automatically. This is available now on non-live tenants and will be enabled on live tenants from 5 October 2026.

ETL Agency Migration can now automatically name new Managed Relationships that are created without a name, using the format "MR - [Investment Manager Legal Entity Name] - [Underlying Principal Legal Entity Name]". Managed Relationships created by the system no longer display as a generic "Managed Relationship", making them easy to tell apart where an Underlying Principal has several. This is available now on non-live tenants and will be enabled on live tenants from 5 October 2026.

ETL Agency Migration can now automatically launch Fenergo journeys for migrated Investment Managers and Underlying Principals once they have loaded, so that follow-up activity such as onboarding, Risk Assessment, Screening or Due Diligence can begin without launching each journey manually. Journey Launch is available now on non-live tenants and will be enabled on live tenants from 2 October 2026.

ETL Agency Migration is a new and separate capability, leveraging ETL to migrate agency objects. It exists for a single purpose: to build the Agency Data Model. It migrates Investment Managers, Underlying Principals, Managed Relationships and Managed Products, and constructs the relationships between them automatically.

ETL Agency Migration brings agency migration into the same self-service, preview-and-validate experience clients already use for standard ETL. It complements standard ETL rather than replacing it — where an Investment Manager or Underlying Principal is also a client, its full client record is still migrated through a standard ETL project.

ETL Screening is now available on all production tenants. Clients migrating from a legacy KYC system can use ETL to load historic screening data — including screening entities, match records, and adjudicated decisions — directly into the Fenergo Screening domain, enabling resolution reuse and NoMatch suppression from day one without requiring a full re-screen.

ETL now supports the bulk deletion of existing association records using the new Delete Associations data type. Combined with the existing Associations data type, this also enables a net update to an association's relationship type in a single ETL project — deleting the old relationship and creating the new one in the same load.

Clients migrating to Fenergo from a legacy KYC system arrive with years of historic screening activity, runs conducted against providers such as RDC, WorldCheck One and LexisNexis, with adjudicated match decisions and materiality assessments already captured in their source system. Without migrating this data, analysts would be forced to re-screen every entity from scratch and rebuild years of compliance decisions from Day 1.

ETL Screening addresses this by enabling clients to load their historic screening data directly into the Fenergo Screening domain.ETL Screening is currently available as a Beta feature while we conduct performance testing. It can be enabled on request, clients interested in this feature should contact their Fenergo representative.

ETL reconciliation reports now include document-level detail on every row, so any row can be traced back to the specific document it relates to. Each row records the Document Model ID, the unique identifier of the document in Fenergo, alongside the Document Path for uploaded documents or the URL for virtual documents.

The additional columns apply to Entity Documents, Product Documents, Entity Virtual Documents, and Product Virtual Documents reconciliation reports, removing the need to cross-reference the original migration bundle when investigating failed loads or post-migration queries.

ETL now automatically triggers journeys for migrated Individual and Company entities once a data load completes, allowing migrated entities to resume in-progress activities such as Risk Assessment, Screening, and Due Diligence without manual intervention.

Journey Launch is configured per entity type, with an optional filter to control which entities are in scope. A Journey Launch report is generated for each entity type, detailing the outcome for every evaluated entity to support reconciliation.

ETL now validates static Access Layers referenced in a migration file during the validation stage, before any entities are loaded. Any Access Layer that does not exist in the tenant configuration is flagged as a validation error, so the file can be corrected before the load proceeds.