An account application is a banking-domain record that collects the information needed to open an account and request associated services. It supports consumers that save data progressively, resume interrupted work, and present a final review before validation. section 10.4.1 section 10.4.5
A practical API can initiate an application, update it, read it, and validate it. Aggregating updates for services, branches, payment cards, and holders simplifies the consumer flow, while unrelated list operations remain separate. section 10.4.4
Design the application flow around the consumer’s data-collection needs:
- Allow partial saving with POST /account-applications and PUT /account-applications/{accountApplicationId}; return COMPLETE or INCOMPLETE status and messages describing missing data. section 10.4.5 section 10.4.6
- Support one-call completion with an optional completion=true modifier when partners or other consumers already have all required data. section 10.4.6
- Separate collection from completion validation so users can review complete data before confirmation. section 10.4.5
- Attach documents directly to the application or store them through a generic file resource, depending on reuse and file-management needs. section 14.3.1
Validating a partial application
POST /partial-account-applications/{accountApplicationId}/validations can create the finalized account application. A 201 response can return its Location, or a 303 See Other response can redirect the consumer to GET /account-applications/{accountApplicationId}. section 10.4.7
Figure 10.9 The operation flow to open an account comprises several data-saving steps that constrain consumer flow. We can fix that.
Use the operation-flow diagram to see how initiation, related data updates, reading, and resumption shape the account-opening experience. section 10.4.1
