Change Request: Adding account information to the **party** data object
mjbrichards opened this issue · comments
Open API for FSP Interoperability - Change Request
Table of Contents
1. Preface
___This section contains basic information regarding the change request.
1.1 Change Request Information
| Requested By | Michael Richards, ModusBox |
| Change Request Status | In review ☒ / Approved ☐ / Rejected ☐ |
| Approved/Rejected Date | |
1.2 Document Version Information
| Version | Date | Author | Change Description |
|---|---|---|---|
| 1.0 | 2020-05-19 | Michael Richards | Initial version. |
2. Problem Description
___2.1 Background
This change request contains information which was originally proposed as part of the Consolidated Change Request prepared by Adrian Hope-Baillie to cover the various changes associated with cross-network and cross-currency functionality.
As part of the linking process by which PISPs and DFSPs agree that a PISP can make debit requests against a DFSP customer's account, the PISP needs to obtain information about the accounts which the DFSP associates with the customer's identifier. This information is the same as the information proposed as part of the consolidated change request, and it is therefore pulled from that request and presented (with some modification) as the content of this change request, so that it can be independently proposed and approved by the CCB
2.2 Current Behaviour
Explain how the API currently behaves.
The information currently returned about a party via the API does not contain any information about either the accounts to which the identifier has access or the currencies in which those acocunts are denominated.
2.3 Requested Behaviour
The Party data model is updated to include a new accounts data element:
| Data Element | Cardinality | Type | Description |
|---|---|---|---|
| accounts | 0..1 | AccountList |
A list of accounts that the Party has in different currencies together with an optional AccountAddress for routing purposes |
Add AccountList and Account data types
The AccountList data model is defined as:
| Data Element | Cardinality | Type | Description |
|---|---|---|---|
| account | 1..32 | Account |
Number of Account elements |
The Account data model is defined as:
| Data Element | Cardinality | Type | Description |
|---|---|---|---|
| currency | 1 | Currency |
The currency of the account |
| description | 0..1 | Name |
The name of the account |
| address | 0..1 | AccountAddress |
The address of this account |
The AccountAddress data type is a variable length string with a maximum size
of 1023 characters and consists of:
- Alphanumeric characters, upper or lower case. (Addresses are case-sensitive so
that they can contain data encoded in formats such as base64url.) - Underscore (_)
- Tilde (~)
- Hyphen (-)
- Period (.) Addresses MUST NOT end in a period (.) character
An entity providing accounts to parties (i.e. a participant) can provide any
value for an AccountAddress that is routable to that entity. It does not
need to provide an address that makes the account identifiable outside the
entity's domain. i.e. This is an address not an identifier
For example, a participant (Blue DFSP) that has been allocated the address space
moja.blue might allocate a random UUID to the account and return the value:
{
"address": "moja.blue.8f027046-b82a-4fa9-838b-70210fcf8137",
"currency": "ZAR"
}This address is routable to Blue DFSP because it uses the prefix moja.blue
Blue DFSP may also simply use their own address if that is sufficient (in
combination with the remainder of the PartyIdInfo) to uniquely identify the
payee and the destination account.
{
"address": "moja.blue",
"currency": "ZAR"
}This address is also routable to Blue DFSP because it uses the prefix
moja.blue
IMPORTANT: The policy for defining addresses and the life-cycle of these is
at the discretion of the address space owner (the payee DFSP in this case)
I think this is consistent with the purpose of the /parties resource which is acts as an information lookup service and is used to obtain information about a Party.
Suggest to consider how compressive this can be so that when another players is added, it would not need another change request for other information to be added.
Thanks for your comments, JM. You're right, of course: this proposal originally formed part of the cross-network changes proposed by Adrian in pull request #22, and that contains quite a large number of changes proposed to support cross-network and cross-currency transfers. However, since this particular change would also be useful for PISP, we agreed that the sensible plan was to pull it out as a separate change request. It is proposed as a non-breaking change which can be implemented quickly, and we can leave the other proposed changes for a full review of the cross-network proposal when we come to consider it as a whole.
Adding a link to issue #19 as well, as that contains the original discussion around the Party data model. Please see my commment #19 (comment) regarding address vs accountAddress. Otherwise I'm fine with this change.
This functionality has now been moved to the third party API and is no longer required for the FSPIOP API