Skip to main content
Design for implementation review only. The /v2 routes on this page are not available. Existing integrations continue to use API 1.4.2. Publishing this design does not deploy an API.

Public boundary

Expose the customer inputs and outputs: borrower, connection session, lending product, risk policy, Origination, risk package, funded-deal monitor, evaluation, alert and evidence. AMLOK owns source collection, normalization, extraction, verification, calculations and orchestration. An institution should not need a manifest ID, child workflow ID, calculation job or processing-context object to obtain an underwriting. Those records may remain internal for reproducibility and support. Download the proposed OpenAPI contract and operation index. The proposal has its own version, 2.0.0-design.1, and is excluded from the current SDK and Postman generators.

Ownership and configuration

The API key’s scopes do not replace console roles. Owners manage organization, workspace, team and billing controls. Owners and Devs manage integration configuration. Analysts read permitted product results and reporting without Dev Tools or billing access. Every export must enforce its underlying data permissions, including Owner authority for billing. Nobody edits or deletes historical product data through these routes.

1. Connect a borrower

Create a typed business or person borrower. The server then creates an embedding session using the borrower ID and published embedding version. Only the short-lived launch URL reaches the borrower browser. The institution key, provider credentials and provider routing remain server-side. The session captures the actual borrower’s authorization. Completion provides connection and consent references; it does not mean all data has arrived. Connection health explains missing access and reauthorization. For reauthorization, create a new session bound to the existing connection. Revoked or expired consent cannot be revived by changing a status value; obtain new authorization. Return URLs must match approved destinations. Session binding, expiry, origin restrictions and callback validation must be enforced by the implementation. A browser success callback is never proof of consent or underwriting completion; verify server-side state or a signed event.

2. Supply the lending context

Create immutable versions of the institution’s lending product and risk policy, or use versions already provisioned for the workspace. Retrieve approved application and pricing schemas through configuration. The lending product must capture borrower type, market, currency, size and term bounds, repayment frequency and validated pricing economics. The submitted application carries the requested amount, term, purpose and institution-specific declared data. Validate that these inputs agree. A policy for a Canadian business cannot silently become a US consumer policy. Policy rules refer to approved dimension keys, units, comparison operators and thresholds. Missing inputs require review. Policy documents are supporting context, not automatically executable rules. Free-text descriptions must not silently become credit decisions. Updating a policy or product means creating a new version; existing packages keep their original versions and hashes.

3. Request an Origination

The institution submits its application, borrower, product version, policy version and authorized connection/document IDs in one command. AMLOK gathers the necessary source data, identifies missing requirements, runs included verification and analysis, freezes the evidence and produces the risk package.
This is a synthetic design example. declared_data must validate against the institution-approved schema; it is not an unrestricted route around input validation. Submitted claims remain distinguishable from provider-observed or independently verified data. An accepted request returns 202 and an Origination ID. Follow the resource or a signed event through collecting, requires_action, processing, waiting_for_credits, completed, failed or cancelled. Requirements point to source connection, reauthorization or document-upload actions. New accepted evidence can resume the same unfinished request within its agreed scope. Completed work is immutable; a new full underwriting is a separate authorized request. Completion checks and deducts Insights credits atomically with package publication. Insufficient credits at that point leave the accepted request waiting without publication or a debit. No separate verification/calculation charges or reserved-credit model is introduced.

4. Retrieve the result and evidence

Read the risk package by the ID returned on completion. It includes product/policy versions, application context, financial dimensions, rule outcomes, source coverage and limitations. Use its evidence-set ID to paginate exact normalized records, provider-report references and original documents. Keep large transaction collections and files outside the main response. Exports support complete risk-package JSON or PDF, normalized evidence JSON/CSV and authorized billing reports. Recheck workspace, consent, retention and provider licensing when reading or downloading. A restricted original file remains restricted even if its derived result is available.

5. Monitor the funded deal

Create a monitor with the borrower, funded-deal terms, approved policy, cadence and either an existing risk package or an approved portfolio-onboarding reference. AMLOK resolves the baseline. Institutions do not need to create internal baseline snapshots or calculation manifests. See Monitoring design.

Reliability and scale

  • All list routes use opaque cursors and bounded pages. Cursors bind workspace, environment, filters and snapshot; a changed filter requires a new traversal.
  • Every POST accepts a stable idempotency key. A reused key with different input fails. Accepted-command recovery must survive the 24-hour cached-response window.
  • Monitor configuration changes require If-Match; stale changes fail with 412. There are no edits or deletes for packages, alerts, source evidence or billing history.
  • Event consumers verify raw-body signatures, persist before acknowledging, deduplicate by event ID and tolerate out-of-order delivery. Replay only repeats delivery.
  • API origins, quotas, event retention and provider freshness are supplied through onboarding. This design does not invent production values or SLAs.

Proposed operation catalog

All routes below belong to the replacement design, not the available v1 contract. Endpoint count is the number of method/path pairs.

Borrowers

Connections

Evidence

Configuration

Insights

Results

Signal

Events

Exports

Billing

Reliability