Synchronizing
Architectural Primitives

Documents and AI extraction

Every upload is classified by document type and its key fields extracted, wherever it was uploaded: the upload page, a form field, a person's identity block, or the review step. The extraction speeds the applicant up without ever taking authorship of their answers away from them.

How extraction is applied

  • Each file is stored once and appears in every part of the form that accepts its type, for example a bank statement as the bank proof and as the matching person's address proof. The applicant can correct the document type on the row.
  • Values read from the documents are reconciled across all of them and filled in automatically. A field the documents filled carries an AI Filled tag until the applicant edits it. A field the applicant filled by hand is never overwritten: the value from the documents is offered as a suggestion in a side drawer and replaces the answer only when they ask.
  • When two documents disagree on a value and the rules cannot settle it, one structured model call picks between the offered document values; it never composes a value. When that cannot decide either, the field is shown as disputed for the applicant to settle.
  • A file uploaded into a specific form field stays in that field, and counts as that field's document, even when it is read as something else or cannot be read at all, so a bad read never blocks submission. The read result stays on the record for staff review.
  • An identity or address document that names nobody on the application waits under Supporting documents; when a matching person is added, the applicant is offered to attach it.
  • Extraction output is schema-checked before it is allowed anywhere near the form.
  • The required-document checklist gates approval. Optional documents are collected but do not block.
  • Uploads are size- and type-checked, and malware-scanned where that is enabled for your deployment.
The applicant stays the author
Every value the documents filled is marked as such until the applicant edits it, an answer the applicant typed is never overwritten, and a value the documents disagree on is settled by the applicant. The submitted record stays attributable to them, which matters when the file is reviewed later. See The applicant portal.

Typical checklist

The exact checklist is part of your intake configuration and is confirmed with you at onboarding. A typical corporate intake looks like this.

RequirementTypical documents
RequiredTrade licence, and the authorised representative’s passport and national ID.
OptionalProof of address, memorandum of association, and tax certificates.

Required documents block approval until they are present. Optional documents are collected for the file but never hold up a decision.

Requesting a missing document

From the Documents tab, a missing or expired required row opens the Requests tab with that document prefilled as an item. The applicant is emailed and told exactly what is needed, and uploads the document against that item in the portal. Only an upload made after the ask satisfies it, so a replacement cannot be met by the file that prompted the request. The rest of their application stays as submitted.

This moves the application to Needs info. See Onboarding lifecycle and The compliance dashboard.

Upload handling
Uploads are size- and type-checked and stored encrypted. Malware scanning is available and enabled per deployment; when it is on it is fail-closed, so an unscannable file is rejected rather than passed through. Confirm the setting for your deployment at onboarding, covered in Security and compliance.