Synchronizing
Architectural Primitives

The onboarding lifecycle

An application runs from creation through the applicant's submission to a decision your compliance team stands behind. Status is server-authoritative throughout, and approval is reachable only through a two-person path.

End to end

A complete onboarding, from the moment you create the application to the final decision.

  1. 1
    Your team or APIAegisCreate application
  2. 2
    AegisYour teamSecure sign-in link returned
  3. 3
    Your teamApplicantSend the link
  4. 4
    ApplicantAegisSign in and accept consent
  5. 5
    ApplicantAegisUpload documents and complete the form
  6. 6
    ApplicantAegisSubmit
  7. 7
    AegisAegisScreen, score, notify your team
  8. 8
    Your teamAegisReview, sign off, decide

Statuses

Status is server-authoritative. The platform sets it, and an applicant can never set it. The one applicant action that moves it is submitting the responses to an information request, which the platform records by returning the case to Pending.

StatusMeaning
PendingSubmitted and in the analyst queue.
Needs infoYour team has asked for something. The applicant answers the open items in the request thread; the form itself stays closed.
HoldParked pending an external step.
Pending approvalAn analyst has proposed approval. A different admin must countersign.
ActiveApproved.
RejectedDeclined.

Permitted transitions

An application enters the lifecycle at Pending when the applicant submits. From there, only the moves below are allowed.

Pending
Needs infoHoldPending approvalRejected
Needs info
PendingHoldPending approvalRejected
Hold
PendingNeeds infoPending approvalRejected
Pending approval
ActivePendingHoldRejected
Active
HoldRejected
Rejected
PendingHold

Three properties matter here.

  • Approval is reachable only from Pending approval. There is no path from any other status directly to Active, which is what makes two-person approval structural rather than a convention someone can skip.
  • Approved and rejected are not terminal. An approved counterparty can later be placed on hold or rejected, and a rejected application can be reopened. Offboarding and reconsideration are part of the lifecycle, not a data-fix exercise.
  • Needs info is tied to an open request. A case enters it when your team raises an information request or sends an answered item back for another round, and returns to Pending when the applicant submits their responses or your team cancels the request. Deciding a case that still has an open request cancels the request.

The completeness gate

An application cannot be approved unless all of the following hold.

  • Screening is complete, with no failed or pending screens.
  • The risk rating has been computed successfully.
  • All required documents are present.
  • Every critical sanctions hit has been dispositioned, after the most recent screen.
  • Every mandatory analyst input has been recorded.

The gate is enforced by the platform. It is not a checklist someone has to remember.

Maker-checker

Approvals require two people: the analyst who proposes, and a different admin who approves. Rejections, holds, and information requests are single-analyst actions.

The audit record is the record of truth
Every decision is written to an append-only audit record. The mutable comment thread is not the record of truth. See Security and compliance.

Where analysts do this work day to day is covered in The compliance dashboard. What the applicant experiences on the other side is covered in The applicant portal.