🏢 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.

8
Endpoints
5
Entity Types
44
Properties
Primary
Resource Type

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

GET Get BizEntities Query with filters and cross-resource search
POST Create BizEntity Create investor with nested accounts and parties
PUT Update BizEntity Replace entity structure
DELETE Delete BizEntity Remove with transaction validation

Account Holdings & Portfolio Queries

GET Account Holdings Portfolio positions and valuations

Parent Relationship Management

POST Create Parent Establish parent-child hierarchies
PUT Update Parent Modify hierarchical relationships
DELETE Delete Parent Remove relationship validation

Core Data Transfer Objects

BizEntityDTO POST, PUT, GET responses Complete entity structure (39 main properties + 5 arrays: Accounts, Addresses, Communications, PaymentDetails, BizEntityParties)
BizEntityParentDTO Parent relationship endpoints Hierarchical relationships for corporate structures (8 properties)
BizEntityPartyDTO Entity operations (nested) Person/Organisation links with shareholding details (13 properties)
AccountDTO Entity operations (nested) Account structure for investment management (10 properties)

Filter Data Transfer Objects

GET endpoints use filter classes to bind query parameters. These are request-only structures for filtering and pagination.

BizEntityFilter GET /BizEntity 19 properties: 10 direct ID lookups (BizEntityID, ProductID, InvestmentID, PersonID, OrganisationID + externals) + 6 FilterField with dot operators (BizEntityTypeID, AccountID, AccountNumber, ExternalAccountId, CreatedDate, UpdatedDate) + UpdatedDateFull + pagination
AccountHoldingFilter GET /BizEntity/Account/Holdings 10 properties: 2 direct lookups (ProductID + external) + 5 FilterField with dot operators (AccountID, ExternalAccountId, AccountNumber, InvestmentID, ExternalInvestmentId) + Date (DateOnly) + 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
        }]
      }
    }
  ]
}
Result: ONE Person record created with ID "PERSON-001", referenced in multiple contexts

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.