This release introduces a new "Clear Value if Trigger Condition Not Met" toggle in the policy editor for entity and product level. When enabled on a data requirement, if all associated trigger conditions for a field are no longer satisfied, any previously saved value is automatically cleared at both the product or entity levels. This ensures that hidden fields no longer store an invalid value. The toggle is opt-in and defaults to off.

See user guide for the full configuration guide and behaviours to note with this new functionality:

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.

Reviewers can now assess Bank Account and Investment Account information directly within the Review & Approvals Task, alongside existing entity, related party, product, and document data. Bank Accounts display in their own list with New/Changed indicators and a field-level Details view; Investment Accounts display with drill-in access to Details, Document Requirements, Funds, Bank Accounts, and Related Parties.

Visibility of individual accounts is enforced by the reviewer's Entity and Search access layers, and existing Review & Approvals commenting, permissions, and approval decision behaviour apply consistently across both account types.

This release delivers two targeted enhancements to the Conflict Resolution Task to improve reviewer efficiency and transparency.

First, categories and tabs with no field-level differences between in-flight and verified data can be optionally hidden by default through the Journey Schema, reducing information overload and helping reviewers focus only on what requires a decision. This behaviour applies to journeys triggered after deployment and can be toggled via task properties.

Second, fields whose values are controlled by conditional value rules can be optionally classified and badged as "Calculated" directly on the task and made read only so the user cannot change their value, ensuring greater transparency and trust in the review process. This behaviour applies to fields at the entity level only currently.

Administrators can now configure negative threshold boundaries in Risk Models. This enables risk models that incorporate mitigating factors — where certain inputs actively reduce the overall risk score — to be configured without restriction.

The Product Related Party Launchpad is a new task type that allows due diligence journeys to be triggered for related parties associated with products in a journey. It operates within a Product Connected Journey, mirroring the behaviour of the Related Party Journey Launchpad V2 in a product relationship context.

Administrators can now configure Ownership and Control requirements for Investment Account Related Parties. Required related parties are displayed to the user directly above the related party grid. Users are prevented from completing the Investment Account task until all required related parties have been added.

The Provider Priorities tab on the External Data Configuration screen now displays only the options relevant to each organisation's setup. Organisations using KYRA:Source continue to have full access to the Rules configuration, while those that do not will see only the default provider setting.

When data is imported via an external provider through KYRA:Source, the audit trail now records the name of that provider — for example, "Orbis" — in the Source field, replacing the previous generic label. Auditors and KYC analysts can accurately trace the origin of each imported data point to its source provider.

KYRA:Docs — Document Data Extraction V2 brings the review of extracted entity data, data groups, and related parties into a single, unified task. Reviewers can now compare extracted information against the current entity record, understand the outcome assigned by KYRA:Docs, and record an explicit resolution before any changes are applied. This release replaces the legacy extraction experience with a more controlled, transparent, and auditable review process — supporting both standard and Maker-Checker journeys.