Three updates. Three fewer ways KYC onboarding can go wrong | March 2026 Inside azakaw

Created by compliance experts. Designed for performance. Built to scale.

Every update to the azakaw platform starts from the same place: a real requirement from a regulated firm managing a real compliance challenge. March's updates are no different. All three address specific operational failure points in the onboarding and risk assessment process, and all three give compliance officers more precise control over the data and decisions that matter.

Update 1 | Locked form fields during customer onboarding

When customer data is populated automatically during onboarding, whether through API integration, OCR or another external source, that data needs to stay intact. A field pre-filled from a verified source should not be editable by the customer completing the form.

azakaw now supports a field-locking control within the onboarding form builder. When a field is marked as officer-only during form setup, the customer sees the data but cannot modify it. The field displays a clear message: this information cannot be edited. The officer retains full access to enter and update values from their end. The customer does not.

This update applies across the key field types used in KYC onboarding: text fields, text areas, select inputs, radio buttons, checkboxes, phone number fields and currency fields.

The practical impact is straightforward. When a KYC officer pre-populates data from a verified source, that data arrives at the point of customer review exactly as it was entered. No accidental overwrites. No data integrity issues downstream. No manual re-verification required because a customer changed a field they should not have had access to.

Update 2 | Document type restriction and identity verification

Uploading the wrong document type during onboarding is a common source of KYC failure. A customer submitting a driving licence under an ID card component, or a passport component accepting a document the system cannot verify, creates downstream risk that manual review alone cannot reliably catch.

azakaw now enforces document type validation at the component level. When a document component is configured for a specific identity document type, such as an Emirates ID or passport, the system validates that the uploaded document matches that configuration. If it does not, the upload is blocked and the customer receives a clear, specific error message before they can proceed.

Expiry date validation is also configurable per component. When enabled, the system checks the document's expiry at the point of upload and prevents the customer from continuing if the document has expired. When not enabled, onboarding continues without interruption.

Configuration is administrator-controlled and component-specific. Allowed document types, expiry validation requirements and error messaging can all be defined per component, meaning onboarding is only blocked when there is a genuine compliance reason to do so.

The result is a verification step that works the same way every time, regardless of who is processing the application. Document type errors are caught at entry, not during review.

Update 3 | Dynamic CRA risk score and status configuration

Risk scoring in compliance is not one-size-fits-all. Different regulators, different risk frameworks and different client types can demand materially different approaches to how risk is classified, scored and actioned. A static, hardcoded risk model serves the platform, not the firm using it.

azakaw now supports fully configurable CRA risk status and scoring. Compliance teams can define their own risk statuses, assign numeric scores to each, set score ranges and customise the colour coding used across the system. Configuration is tenant-specific, meaning each firm's risk model applies only to their environment and does not affect other users of the platform.

What this means in practice: a firm using a five-tier model with statuses from Low to Prohibited can configure that model directly in the system. A firm using a different scale entirely, with more granular tiers and different score weightings, can do the same. The CRA calculation, the customer profile display, the dashboard, the review date workflow and all downstream reports all reflect the configured model automatically.

The change also applies to the risk override function. Previously, the override dropdown was limited to a fixed set of statuses. It now pulls from the firm's configured list, so the override reflects the same model as the rest of the assessment.

What stays the same

All three updates are built on the same principle that runs through azakaw: the compliance officer makes the decisions. The platform gives them better tools, more accurate data and fewer process-driven errors to manage. The expertise stays with the team. The infrastructure gets out of the way.

More updates are in development. If you have a requirement you would like to discuss, the team is available at azakaw.com/request-a-demo.