|An identifier for the account that MUST NOT leak the account number or other identifier normally used by the customer or bank staff.
|
|### Format
|
|`account_id` **MUST be a UUID**. The MUST is deliberate: a UUID is effectively globally unique by construction (collision probability ≈ 0), which means `(OBP, account_id)` is a self-contained, federation-safe routing pair without needing to be qualified by the surrounding `bank_id`. Older OBP releases said "SHOULD be a UUID" — the contract has been tightened.
|
|It MUST also be unique in combination with the BANK_ID (this remains true and is enforced at the database level).
|
|### Why a UUID
|
|- ACCOUNT_ID is used in many URLs so it must be considered public; a UUID leaks no information about the account number, customer, or position in any sequence.
|- (We do NOT use the human-facing account number in URLs since URLs are cached and logged all over the internet.)
|- A UUID also makes the canonical `(OBP, account_id)` self-routing (see `Account.account_routings`) usable across instances without ambiguity.
|
|### How it is generated
|
|- In local / sandbox mode, ACCOUNT_ID is generated as a UUID and stored in the database.
|- In non-sandbox modes (RabbitMQ, etc.), ACCOUNT_ID is mapped to core-banking account numbers / identifiers at the South-Side Adapter level. The adapter is responsible for emitting a UUID-shaped value.
|- ACCOUNT_ID is used to link Metadata and Views, so it MUST be persistent and known to the North Side (OBP-API).
|
| Example value: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
|