Application types and states

Reference for all application types and their statuses

Application types and states describe why an application exists, where it is in the review process, and which actions are available.

Application types

The application type field identifies the purpose of an application.

Type	Description
ONBOARDING	Initial application used to onboard a client. Partners can create this application type.
INFORMATION_UPDATE	Application used to update customer information and send RFIs. Partners cannot create this application type.
PERIODIC_REVIEW	Application used to require customers to review and resubmit information. Partners cannot create this application type.

Application statuses

Status	Description
DRAFT	Created but not yet submitted. Data can be added, updated, or deleted.
SUBMITTED	Submitted for review. No modifications allowed.
IN_REVIEW	Compliance review in progress (automated and manual checks).
PENDING_CUSTOMER_INFORMATION	One or more RFIs issued. Partner must update data or documents and resubmit.
APPROVED	Approved. Terminal state.
DENIED	Denied. Terminal state.
CANCELLED	Canceled. Terminal state.

Status transitions

See Application types for definitions of ONBOARDING, PERIODIC_REVIEW, and INFORMATION_UPDATE.

ONBOARDING applications

PERIODIC_REVIEW applications

The system creates periodic review applications in IN_REVIEW, then moves them to DRAFT when partner action is required.

INFORMATION_UPDATE applications

The system creates information update applications in IN_REVIEW. They move to PENDING_CUSTOMER_INFORMATION only when partner action is required.

See Submit and track applications for the submission and RFI workflow.

Mutable vs. immutable states

Partners can only modify application data (sections, documents) in these states:

• DRAFT: Initial state after creation. Full read/write access.
• PENDING_CUSTOMER_INFORMATION: RFIs issued. Partners can update the sections and documents referenced by the RFIs, then resubmit.

All other states are immutable. API calls that attempt to modify data return a 409 Conflict error.

Saving section data in mutable states may trigger conditional changes. See Conditional logic for details.

Section statuses

Each section in an application has its own status that tracks data completeness:

Status	Description
not_started	No data saved for this section
incomplete	Some data saved but required fields are missing
complete	All required fields are populated and valid
action_required	An RFI targets a field in this section; update needed

Terminal states (APPROVED, DENIED, CANCELLED) are final. Applications cannot transition out of these states.