Data Model
Overview of how the different API endpoints relate to each other
Overview
Data Model
Entity Definitions
Authorising-User
Represents your Application's End-User. They are the real world person who:
- executes the Consent Journey,
- authenticates with their credentials at the Account Servicer, and
- consents to allowing your Application to access their data on their behalf.
The two supported End-User to Account Servicer relationship models are:
The End-User is the account holder: The End-User is an individual in the real world who has consented to give your Application access to Account Information from their account. In this scenario they are the customer that has a direct relationship with the account(s).
The End-User is an agent. An agent has a relationship with the customer who holds the accounts to which the account information relates. EG: The End-User is a Financial Advisor or Wealth Manager who has consented to give access to their account on an Advisory Platform or Wealth Management System. Through that account they manage 1 to n customer(s) who each have relationships with 1 to n account(s).
End-User Types
The authorising user's consent can yield access to one or more servicing organisations, reflecting their level of access on the account servicer platform.
For example:
- An Authorising User can be an Advice Network administrator who can access multiple Advice Firms within the network, each represented as a separate Servicing Organisation.
- An Authorising User can be an Adviser who can only access their own Advice Firm.
Servicing Organisation
An organisation which provides financial services/products to an end-customer. This could be a Wealth Management Firm, Financial Advice Firm, or the Platform Provider itself in the case of direct-to-consumer account servicers.
The authorising user's consent yields access to one or more servicing organisations, and mirrors the user's access to servicing organisations on the account servicer platform.
Servicing Agent
A financial agent within a Servicing Organisation who is responsible for servicing a subset of that organisation's Customers and Accounts.
This is a typically a real world person who operates within and for the servicing organisation e.g. a wealth manager, financial planner, para-planner, or an administrator.
The authorising user's consent yields access to one or more servicing agents belonging to one or more servicing organisations, and mirrors the user's access to servicing agents on the account servicer platform.
Account
Represents a financial account within which transactions occur and against which holdings and a cash-balances are held.
For example:
- A bank account
- Individual Savings Accounts (ISAs)
- General Investment Accounts (GIAs)
The authorising user's consent yields access to one or more account, and mirrors the user's access to accounts on the account servicer platform.
Account Group
A logical grouping of accounts that represents a set of accounts owned by a common set of customer(s).
The Account Group entity is not mandatory in the data model; Customers are mapped to both Accounts and Account Groups, which allows us to support querying at both an Account and Account Group level for a given Customer.
For example:
An Advisor or Wealth Manager might manage multiple accounts as part of a mandate or family group. The account group entity would represent this grouping.
Customer
A real world person that has a relationship with an account; the relationship is defined by Customer Account Role attribute.
The authorising user's consent yields access to customers associated with the accounts that they can access on the account servicer platform.
Updated 7 months ago
Enumerations
Different Account Servicer may use different naming conventions for enumerations such as account types, transaction types etc. Where an entity has a type enumeration, the account servicer (source) names are included in the corresponding APIs via a sourceType property.
We map these source types to a set of normalised enumerations contained in type and optionally subType. These normalised enumerations are described below.