BizEntity Resource
The foundational investor identity in the 7G Registry Platform
BizEntity represents the complete investor identity across all entity types - Individual, Company, Trust, SMSF, and Partnership. Serves as the central aggregation point for all investor-related data including accounts, holdings, party relationships, addresses, communications, payment details, and transaction history. Every investment operation flows through a BizEntity.
BizEntity is the primary API resource for investor operations. Most Person, Organisation, Address, Communication, and PaymentDetail management occurs through BizEntity operations. Direct endpoints exist for specialized scenarios like bulk imports or data migration.
🏗️ Ecosystem Foundation
The primary aggregation entity in the 7G platform - every transaction, distribution, holding, and relationship connects through a BizEntity. It's the "investor identity" that ties everything together.
🔗 Central Hub Design
Manages relationships between Person/Organisation (via BizEntityParty), multiple Accounts with Holdings, Addresses, Communications, PaymentDetails, and supports parent-child hierarchies.
⚡ High-Performance Filtering
Advanced GET operations with dot operator filtering across 15+ parameters including typed filters for BizEntityTypeID, AccountID, and complex cross-referencing by Person/Organisation/Product/Investment.
Available Endpoints
Core Operations
Account Holdings & Portfolio Queries
Parent Relationship Management
Core Data Transfer Objects
Filter Data Transfer Objects
GET endpoints use filter classes to bind query parameters. These are request-only structures for filtering and pagination.
🔄 Dual-Approach Creation Pattern
BizEntity operations support two approaches for managing related Person and Organisation records:
📌 Reference Approach
Link to existing Person/Organisation records using their IDs:
{
"bizEntityParties": [{
"personID": 5001, // Native ID reference
"externalPersonId": "PERSON-001", // Or external ID
"isPrimaryContact": true
// No nested person object needed
}]
}
- ✓ Lightweight payload
- ✓ Reuses existing records
- ✓ Prevents duplication
📦 Full Structure Approach
Create or update complete Person/Organisation within BizEntity:
{
"bizEntityParties": [{
"person": { // Full nested object
"externalPersonId": "PERSON-001",
"firstName": "John",
"lastName": "Smith",
"addresses": [...], // Nested addresses
"communications": [...] // Nested communications
},
"isPrimaryContact": true
}]
}
- ✓ Single API call for complete setup
- ✓ Atomic creation/update
- ✓ Full data consistency
🔗 Person Reuse & Deduplication Logic
⚡ Critical Pattern: ExternalPersonId Reuse
When the same externalPersonId
appears multiple times in a single BizEntity request,
the 7G platform automatically deduplicates and reuses the Person record. This prevents creation
of duplicate persons and maintains referential integrity.
How Person Reuse Works
Example: Same person as both primary contact and organisation director:
{
"bizEntityParties": [
{
"person": {
"externalPersonId": "PERSON-001", // First occurrence - creates person
"firstName": "John",
"lastName": "Smith"
},
"isPrimaryContact": true
},
{
"organisation": {
"name": "Smith Holdings Pty Ltd",
"associatedPersons": [{
"externalPersonId": "PERSON-001", // Reuses same person - no duplicate
// System links to existing PERSON-001 created above
"isSignatory": true
}]
}
}
]
}
ExternalPersonId Placement Rules
Context | Correct Field Location | Purpose |
---|---|---|
BizEntityParty with Person | bizEntityParty.person.externalPersonId |
Entity-level identifier for person creation/reuse |
Organisation Associated Person | associatedPersons[].externalPersonId |
Entity-level identifier for person linkage |
Reference Only (no creation) | bizEntityParty.externalPersonId |
Linking-level reference to existing person |
⚠️ Important: Entity-Level IDs Control Deduplication
The system uses the entity-level externalPersonId
(within the Person object)
as the primary deduplication key. Linking-level IDs are secondary references. Always populate the
entity-level ID when creating or reusing persons within complex structures.
Validation & Error Handling
Deduplication Validation Rules
When Deduplication Occurs
- Request Scope: Deduplication applies only within a single API request. Same externalPersonId across separate requests creates distinct person records.
- First Occurrence Wins: The first occurrence of an externalPersonId with full person details establishes the person record. Subsequent occurrences reuse it.
- Minimal Reference Pattern: Second and subsequent occurrences only need externalPersonId - all other person fields ignored (firstName, lastName, etc.).
- Mixed Context Support: Same person can appear in bizEntityParties[], organisation.associatedPersons[], and nested address.person references.
Common Validation Errors
- Missing Entity-Level ID: If person object provided without externalPersonId, system creates new person each time (causes duplicates).
- Inconsistent Person Data: If same externalPersonId appears with conflicting details (different firstName), validation may fail or first occurrence data prevails.
- Orphaned Linking IDs: Using bizEntityParty.externalPersonId without corresponding person.externalPersonId requires pre-existing person record.
Error Messages
// 400 Bad Request - Person not found
{
"result": false,
"message": "Person with ExternalPersonId 'PERSON-001' not found",
"data": {}
}
// 400 Bad Request - Missing required person details
{
"result": false,
"message": "FirstName is required. | LastName is required.",
"data": {}
}
Advanced Deduplication Scenarios
Complex Multi-Role Patterns
Scenario 1: SMSF with Individual Trustees
Self-managed super fund where same person serves as member AND trustee:
{
"bizEntityTypeID": 4, // SMSF
"name": "Smith Family Super Fund",
"bizEntityParties": [
{
"person": {
"externalPersonId": "JOHN-SMITH",
"firstName": "John",
"lastName": "Smith"
},
"isMember": true
},
{
"person": { "externalPersonId": "JOHN-SMITH" }, // Reuses same person
"isTrustee": true
},
{
"person": {
"externalPersonId": "JANE-SMITH",
"firstName": "Jane",
"lastName": "Smith"
},
"isMember": true,
"isTrustee": true // Single party with dual role
}
]
}
Result: Two person records created (John, Jane). John has two BizEntityParty records (member + trustee). Jane has one BizEntityParty with dual flags.
Scenario 2: Trust with Corporate Trustee
Discretionary trust where company serves as trustee and individuals are directors + beneficiaries:
{
"bizEntityTypeID": 3, // Trust
"name": "Smith Family Trust",
"bizEntityParties": [
{
"organisation": {
"name": "Smith Trustees Pty Ltd",
"externalOrganisationId": "TRUSTEE-CO",
"associatedPersons": [
{
"person": {
"externalPersonId": "JOHN-SMITH",
"firstName": "John",
"lastName": "Smith"
},
"relationshipTypeID": 1, // Director
"isSignatory": true
},
{
"person": {
"externalPersonId": "JANE-SMITH",
"firstName": "Jane",
"lastName": "Smith"
},
"relationshipTypeID": 1, // Director
"isSignatory": true
}
]
},
"isTrustee": true
},
{
"person": { "externalPersonId": "JOHN-SMITH" }, // Reuses director
"isBeneficiary": true
},
{
"person": { "externalPersonId": "JANE-SMITH" }, // Reuses director
"isBeneficiary": true
}
]
}
Result: Two person records (John, Jane). Each appears three times: company director (within organisation), and trust beneficiary.
Scenario 3: Parent-Child Entity Relationships
Master fund with sub-funds sharing same advisor as contact across entities:
// First Request: Create master fund with advisor
{
"name": "Master Investment Fund",
"externalBizEntityId": "MASTER-001",
"bizEntityParties": [{
"person": {
"externalPersonId": "ADVISOR-001",
"firstName": "Sarah",
"lastName": "Johnson"
},
"isPrimaryContact": true
}]
}
// Second Request: Create sub-fund referencing same advisor
{
"name": "Sub Fund A",
"externalBizEntityId": "SUB-001",
"parentBizEntityID": 10001, // Links to master fund
"bizEntityParties": [{
"externalPersonId": "ADVISOR-001" // Reuses existing person across entities
}]
}
Result: Single person record "ADVISOR-001" referenced by both master and sub-fund entities. Cross-entity reuse requires person to exist before second request.
Business Rules & Constraints
BizEntity Integration & Ecosystem
- BizEntity is the foundational resource - all transactions, distributions, and holdings reference a BizEntity
- Complete entity creation includes nested Accounts, Addresses, Communications, PaymentDetails, and Parties in a single operation
- BizEntityParty records link to either Person OR Organisation (mutually exclusive)
- Multiple party relationships per entity support roles like investor, signatory, controller, beneficial owner
- Parent-child entity hierarchies enable complex corporate and trust structures
- Account holdings aggregate across all accounts within the entity
Validation & Business Logic
- FluentValidation: BizEntityValidator enforces Name (required), BizEntityTypeID/StatusID > 0, at least one Account and BizEntityParty, TaxationCountryCode = 3 characters, and SAME PRODUCT RULE (all accounts must share ProductID or ExternalProductId)
- Entity cannot be deleted if active BizTransaction, Distribution, or BizEvent records exist
- TaxationCountryCode validated as 3-character ISO code
Performance & Advanced Features
- Native IDs (BizEntityID) provide optimal performance; External IDs for integration flexibility
- GET operations support 15+ filter parameters with typed filters (FilterOfInt32, StringFilter)
- Cross-resource filtering by ProductID, InvestmentID, PersonID, OrganisationID for complex queries
- Account Holdings endpoint provides real-time investment position data
- Dual ID system: Native IDs for performance, External IDs for third-party system integration
- Bulk entity operations supported for large-scale onboarding and portfolio management
🔄 Ecosystem Workflow Integration
BizEntity connects with transaction processing, investment management, and reporting workflows:
Transaction & Distribution Workflows
Deposit-to-distribution lifecycle with payment routing and tracking.
Investment & Holdings Management
Portfolio tracking with pricing, allotment processing, and redemptions.
Reporting & Document Integration
Investor reporting with statement generation and tax documentation.
Entity Relationship Ecosystem
Person and organisation management with deduplication and multi-role support.