We’ve upgraded the related party data model to support many-to-many associations. A related party can now be linked to multiple investing entities. This article summarises the operational impact and API changes.
What’s Changed
Previously, when the same person was a related party (such as a beneficial owner, trustee, or director) for multiple investing entities, their details had to be entered separately each time. This meant duplicate records, repeated identity verification requests, and extra administrative work.
With this update:
You can search for and link existing related parties when building out an investing entity’s related party tree
Individual related parties only need to complete identity verification once, and their KYC data will automatically apply across all relationships
You can still mark a relationship as exempt from KYC on a per-relationship basis
You can add notes to capture and retain information about inactive relationships
Changes to the Investor Experience
Once a related party has completed identity verification for one relationship, that verification will apply to all of their relationships across investing entities. You can still re-trigger an updated electronic verification at any time in line with your compliance programme.
Note: There is no change to how accounts access or use the Investor Portal. Portal login credentials and permissions remain unchanged.
Data Migration
As part of these changes, KYC data now sits on related party records rather than account records. To preserve your existing data, every account that held KYC information has been automatically recreated as an individual related party, retaining all details and verification history. As some documents and notes are related to KYC activities, these are duplicated from the account to the linked related party.
Each of these new individual related party records is linked back to the originating account, so the connection between the two is clear. You’ll see this new ‘link’ feature displayed in the header of both the account and the related party.
To give you full visibility of where these records sit in your fund structure, each migrated individual related party has also been added to the related party tree of every investing entity the original account had access to. These appear with the relationship type Migrated account.
No action is required. Your existing data is intact and accessible from both the account and the related party record.
Data Deduplication
Because the previous system required the same person’s details to be entered separately for each investing entity, many datasets contain duplicate related party records.
Caruso will run an internal cleanup process to identify likely duplicates using matching rules based on name and other personal identifiers. After initial findings, our team will work with you to review and merge any duplicates.
You do not need to take any action now. We will reach out directly when it is time to review your data.
Key Terminology
Term | What it means |
Account | A person-level CRM record used to manage relationship history with the fund and control investor portal access. Accounts no longer hold KYC data. A new feature links an account to an individual related party to reference the unique natural person. |
Related party | An individual or entity associated with an investing entity (for example a beneficial owner, trustee, director, or partner). Identity verification, KYC, and compliance details are captured and maintained here. |
Investing entity | The legal investing vehicle (for example an individual, trust, company, or partnership) that holds units. An investing entity can have one or more related parties associated with it. |
API Change Notice
The items below are deprecated but continue to work until 14 April 2026.
What’s deprecated | Replacement | Removal date |
| Query via Account.relatedPartyLink.relatedParty instead | 14 Apr 2026 |
| Use requestBeneficialOwnerVerification / manuallyVerifyBeneficialOwnerIdentity / manuallyVerifyBeneficialOwnerAddress | 14 Apr 2026 |
| addRelatedParty / deleteRelatedParty | 14 Apr 2026 |
Legacy input fields: | Use parentAssociationId, relationships [], beneficialOwnerEntityType | 14 Apr 2026 |
| updateRelatedPartyInvestingEntityAssociation | Future release |
searchInvestorProfiles filter: | Filter via related party status | 14 Apr 2026 |
Do I Need to Take Action?
You query Account KYC fields (
identityVerificationStatusetc) – Yes, migrate to related party KYC before 14 April 2026.You use account-level KYC mutations – Yes, switch to the BeneficialOwner equivalents before 14 April 2026.
You use
addBeneficialOwner/deleteBeneficialOwner– These still work. Plan to migrate to the new mutations at your own pace before April.You read
relationship,parent, orassociatedInvestingEntity– Update your type generation to handle null values, but no functional change is required immediately.You don't use beneficial owner or KYC endpoints – No action required.
Newly Available APIs
The following APIs are now publicly documented and available for use:
addRelatedParty/deleteRelatedParty– preferred mutations for related party managementupdateRelatedPartyInvestingEntityAssociation– manage relationship type and exemption per associationInvestingEntity.relatedPartyAssociations– traverse the full many-to-many graphsearchRelatedParties,searchInvestingEntities(relatedPartyIDs: [ID!])– cross-association queries
Full API reference documentation is available at documentation.api.getcaruso.com
Related Articles
If you’re unsure whether these changes affect your integration, or need help migrating a specific call, please reach out to [email protected].