Skip to main content
Protect your integration with tenant-scoped access, least privilege, and controlled evidence handling. See Security & Compliance for AMLOK platform controls and privacy practices.

​
Institution and subject boundaries

Bind requests to the tenant represented by the API key. Check ownership of every referenced subject, document, connection, manifest, and snapshot. A valid ID from another tenant must not become visible through a relationship, filter, download, or event. Grant the smallest useful scopes. Separate service accounts by environment and workload. A read-only analytical service should not hold workflow-execution or configuration-write permissions. Record the authorized purpose, consent policy version, evidence, and relevant scope. Re-check these constraints when collecting, reading, exporting, or sending data. Revocation stops new collection but does not bypass an applicable retention or legal-hold policy. Mask or tokenize restricted identifiers by default. Avoid storing unnecessary identity data in your own system. Raw biometric media, PAN, CVV, and provider secrets are not part of the normalized default response.

​
Audit trails

Capture institution, service identity, purpose, operation, resource version, correlation ID, and outcome in your restricted audit system. Record the analysis configuration, input versions, and result reviewed. Preserve evidence manifests and immutable decision snapshots. Redact keys, webhook secrets, signed URLs, raw documents, and sensitive payload fields. Do not rely on broad request/response logging as an audit strategy.

​
Webhook and outbound destination controls

Register only institution-controlled HTTPS destinations. Deployment must validate destinations against SSRF, private-network targets, unsafe redirects, and tenant policy. Receivers verify signatures over raw bytes and durably deduplicate events.

​
Retention and incident handling

Authorized users manage retention in the AMLOK platform according to applicable compliance frameworks. Completed workspace deletion removes all associated workspace data. Necessary final billing, refund, and bank-return records are retained separately without borrower source data, documents, analysis outputs, or active workspace access. Workspace deletion is managed in the platform, not through a public deletion-request API. Cancellation may be requested at any time without notice through the client portal or a dedicated enterprise account manager. Closure is at the end of the request month, with an immediate full unused-credit refund to the saved bank account. Deletion occurs after that month closes and final information is generated. Before production, agree data locations, retention rules, encryption/key-management requirements, breach-reporting channels, access reviews, incident contacts, and support escalation. Record these settings during integration onboarding.