Skip to main content

​
Verify an applicant

Create a business/person, obtain authorization, and upload permitted evidence. An included stage needs an existing unfinished Insights run or active paid Signal period. For owner KYC in a business assessment, follow related-person verification. Start verification as an included stage, with an approved workflow version and authorized processing_context. If a hosted URL is returned, route the applicant through it and wait for the result. Retrieve checks and screening matches. in_review, unresolved identity, missing ownership evidence, and possible screening matches require explicit handling. Completion is not the same as a verified identity or institutional approval. See the runnable product journeys for linked requests and billing assertions.

​
Underwrite from frozen evidence

  1. Create the application with exact amount and currency.
  2. Connect and synchronize authorized sources, then inspect coverage and freshness.
  3. List ready input manifests for the subject after synchronization. Use the returned manifest ID for the underwriting and its included calculations, with a calculation window contained in the frozen manifest window. Retrieve the manifest to confirm coverage; missing coverage is not a zero value.
  4. Start an underwriting run with workflow_type: underwrite, an approved version, application_id, input_manifest_id, and input resource IDs present in that manifest. Included calculation requests identify this parent in processing_context.
  5. Retrieve the decision and immutable risk snapshot. Distinguish an advisory recommendation from the institution’s decision.
Missing inputs produce explicit unavailability. Do not replace an unavailable DSCR, credit score, PD, or income verification with an inferred value. Provider bank deposits alone do not establish gross income or employment.

​
Observe funding

The API exposes lender-supplied loans, facilities, guarantees, collateral, and repayment schedules. Credit reporting shows prepaid AMLOK service credits and consumption. It provides no payment controls. Borrower funding and filings remain in the institution’s authorized systems.

​
Monitor an existing exposure

  1. List ready monitoring baselines for the borrower/business. AMLOK prepares these from a completed assessment or the agreed existing-portfolio onboarding process. If none is ready, complete that process before creating a monitor.
  2. Retrieve the baseline and its linked risk snapshot. The response provides the frozen input-manifest ID and approved snapshot ID.
  3. Create a monitor using the returned snapshot_id as baseline_snapshot_id, with resource types, attribute keys, cadence, and ruleset version. All linked IDs must belong to the same subject and key-bound workspace.
  4. Consume alerts and retrieve supporting evidence. Baseline reads do not launch or charge an Insights underwriting.
Compare comparable time windows and coverage. A data outage is not an improvement in borrower risk. Refresh cadence depends on source capability and consent; a daily requested cadence is not a source freshness guarantee. For a material change, Signal reassesses risk using existing baseline data and newly processed records. Each updated version counts as a new record; retries and repeated reads of the same unchanged version do not count again. This work is included in Signal and does not launch or charge another Insights underwriting. Preserve the original snapshot and the new evidence for audit. A separately requested full underwriting is a distinct Insights operation.

​
Review intervention signals

Read alerts alongside the current risk snapshot, the monitoring baseline, and supporting source evidence. Review severity, the rule or threshold that triggered the alert, data freshness, and missing coverage before deciding whether intervention is needed. Signed webhooks notify your institution’s registered systems that results or alerts are available. They do not contact borrowers. Your institution decides whether and how to intervene using its own staff, policies, and systems. Use workflow_type: investigate with the existing product processing_context to analyze suspicious evidence or related-party signals. Its purpose is evidence review and risk assessment. AMLOK does not create servicing cases, assign follow-up tasks, send borrower messages, collect repayments, or manage payment promises.

​
Four assessment workflow types

verify, underwrite, monitor, and investigate are the workflow enum values. Funding and re-underwriting are lifecycle journeys, not additional enum values. See product scope, processing lifecycle, and evidence traceability.