# Myaza Trust

> Integration guides for identity verification, workflows, Risk Intelligence and Travel Rule. Read product decisions and failure handling as well as endpoint schemas.

## Discovery

- [Machine index](https://trust.myaza.co/documentation/index.json): all guides, integration skills and content digests.
- [Public v1 OpenAPI](https://trust.myaza.app/api/openapi.json): /api/v1 operations only; KYC and Identity APIs use separate guide contracts.
- [Agent guide](https://trust.myaza.co/documentation/ai-integration/markdown): API boundaries, security and acceptance.

## Integration skills

- [Identity verification](https://trust.myaza.co/documentation/skills/verification/SKILL.md): Capture identity evidence and return an actionable verification outcome.
- [Workflows and decisioning](https://trust.myaza.co/documentation/skills/workflows/SKILL.md): Design a customer journey and apply the organisation's published decisions.
- [Business verification](https://trust.myaza.co/documentation/skills/business-verification/SKILL.md): Verify businesses and the people associated with them.
- [Risk Intelligence](https://trust.myaza.co/documentation/skills/risk-intelligence/SKILL.md): Connect customer evidence to reviewable, measurable risk decisions.
- [Screening](https://trust.myaza.co/documentation/skills/screening/SKILL.md): Screen people, businesses and wallets and respond to potential matches.
- [Events and continuous monitoring](https://trust.myaza.co/documentation/skills/monitoring/SKILL.md): Observe changing customer risk and assess account activity or custom events.
- [Transactions and fraud decisions](https://trust.myaza.co/documentation/skills/transactions/SKILL.md): Assess fiat and crypto transactions before the customer's system acts.
- [Travel Rule](https://trust.myaza.co/documentation/skills/travel-rule/SKILL.md): Exchange transfer information securely and obtain an enforceable current decision.
- [Crypto operations](https://trust.myaza.co/documentation/skills/crypto-operations/SKILL.md): Manage crypto institutions, saved destinations and deposit observations.
- [Address Intelligence](https://trust.myaza.co/documentation/skills/address-intelligence/SKILL.md): Assess address evidence and maintain address confidence over time.
- [Investigations and reporting](https://trust.myaza.co/documentation/skills/investigations/SKILL.md): Triage findings, document decisions and measure policy quality.
- [Webhooks and operations](https://trust.myaza.co/documentation/skills/webhooks/SKILL.md): Deliver results reliably to the customer's system.

## Guides

- [Introduction](https://trust.myaza.co/documentation/introduction/markdown): Choose the Myaza Trust identity-verification or Risk Intelligence integration journey.
- [Quickstart](https://trust.myaza.co/documentation/quickstart/markdown): Run a complete identity verification from your terminal in a few minutes.
- [Authentication](https://trust.myaza.co/documentation/authentication/markdown): Create API keys and authenticate every request with a Bearer token.
- [Environments](https://trust.myaza.co/documentation/environments/markdown): Sandbox vs production, test vs live keys, and going live.
- [Integrate with AI](https://trust.myaza.co/documentation/ai-integration/markdown): Give your coding agent the contracts, product context and tests needed to build a reliable integration.
- [Status and reliability](https://trust.myaza.co/documentation/status-and-reliability/markdown): Where to check live service status, and how to get Myaza Trust's measured availability for your security review.
- [Get configuration](https://trust.myaza.co/documentation/api-config/markdown): GET /config: discover the ID types and features enabled for your organisation.
- [Upload media](https://trust.myaza.co/documentation/api-upload/markdown): POST /upload: store a document, selfie, or liveness file and get a mediaId.
- [Create a verification](https://trust.myaza.co/documentation/api-create-verification/markdown): POST /verify, submit an identity for verification. The core endpoint.
- [Get verification status](https://trust.myaza.co/documentation/api-verification-status/markdown): GET /status/:verificationId, minimal, publishable-safe submission status (no PII).
- [Get verification result](https://trust.myaza.co/documentation/api-verification-result/markdown): GET /verifications/:id, full verification result with PII. Secret key only.
- [Face match](https://trust.myaza.co/documentation/api-face-match/markdown): POST /face/compare: compare two photos 1:1 and get a verdict, synchronously.
- [Create a session](https://trust.myaza.co/documentation/api-create-session/markdown): POST /sessions, mint a hosted verification link for one applicant, server to server.
- [Errors](https://trust.myaza.co/documentation/errors/markdown): HTTP status codes, error response shapes, and the health check.
- [Rate limits](https://trust.myaza.co/documentation/rate-limits/markdown): Request limits and how to handle 429 responses.
- [Verify again](https://trust.myaza.co/documentation/api-verify-again/markdown): POST /verifications/:id/rerun, ask the applicant to redo a finished verification, whole or in part, server to server.
- [Decide a verification](https://trust.myaza.co/documentation/api-review-verification/markdown): POST /verifications/:id/review, approve, decline or send back a finished verification from your backend, or change an earlier decision.
- [List verifications](https://trust.myaza.co/documentation/api-list-verifications/markdown): GET /verifications: page through your verification history server to server.
- [Spot checks](https://trust.myaza.co/documentation/api-spot-checks/markdown): POST /checks: run one-off individual and business checks server to server, and read their history.
- [Delete, expire & cancel](https://trust.myaza.co/documentation/api-manage-records/markdown): DELETE /verifications/:id, DELETE /checks/*/:id, DELETE /face/checks/:id, POST /sessions/:id/expire and POST /sessions/:id/cancel: remove a record, end a live session early, or stop a session or a processing verification and take that back.
- [Email & SMS verification](https://trust.myaza.co/documentation/api-contact-verification/markdown): Send a one-time code to an email address or phone number, then check it. Synchronous, no SDK.
- [API explorer](https://trust.myaza.co/documentation/api-explorer/markdown): Search public v1 endpoints and inspect request and response fields.
- [On-Demand Wallet Screening API](https://trust.myaza.co/documentation/api-wallet-screenings/markdown): Screen a wallet address with a secret API key and retrieve its risk result.
- [Supported countries](https://trust.myaza.co/documentation/countries/markdown): Every country Myaza Trust covers, the government-database KYC markets, global document verification, and the business (KYB) registry list.
- [Address Intelligence](https://trust.myaza.co/documentation/address-intelligence/markdown): Smart-address capture (map pin, entrance photo, directions) and how the platform corroborates it against the evidence it already holds.
- [Background Location Declarations](https://trust.myaza.co/documentation/background-location-declarations/markdown): A store-review kit for apps that turn on background presence verification: how to frame it for your product, the Play Console answers, the in-app disclosure, a 30-second video script, Apple review notes and what to do if you are rejected.
- [Hosted link events](https://trust.myaza.co/documentation/hosted-events/markdown): Listen to a hosted verification's lifecycle from a React Native or Flutter WebView, or from an iframe.
- [Webhooks](https://trust.myaza.co/documentation/webhooks/markdown): Receive signed event notifications and verify their authenticity.
- [Sandbox & test IDs](https://trust.myaza.co/documentation/sandbox-testing/markdown): Test your full integration with canned test IDs, every outcome and no external check cost.
- [Workflows](https://trust.myaza.co/documentation/workflows/markdown): Build a verification flow visually once, then embed it by id or share it as a hosted link, with no redeploys.
- [Decisioning](https://trust.myaza.co/documentation/decisioning/markdown): Turn verification data into an approve / decline / review decision with a visual rules graph.
- [Lists](https://trust.myaza.co/documentation/lists/markdown): Blocklists, the face allowlist, the High-risk countries list, and the custom lists you create for your workflow rules.
- [SDKs](https://trust.myaza.co/documentation/sdks/markdown): The server-side Risk Intelligence SDK and client verification SDKs.
- [Web SDK (React)](https://trust.myaza.co/documentation/sdk-react/markdown): Drop-in <MyazaKYC /> button and modal verification flow for React (≥ 18).
- [React Native SDK](https://trust.myaza.co/documentation/sdk-react-native/markdown): On-device native liveness for React Native / Expo, with the same API as the web SDK.
- [Flutter SDK](https://trust.myaza.co/documentation/sdk-flutter/markdown): MyazaKYC.show() modal verification flow for Flutter / Dart with on-device liveness.
- [User Verification](https://trust.myaza.co/documentation/user-verification/markdown): Launch your first individual verification with a hosted link or an SDK.
- [Verification lifecycle](https://trust.myaza.co/documentation/verifications/markdown): How a verification moves from pending to a final status, and how to handle each.
- [Countries & ID types](https://trust.myaza.co/documentation/id-types/markdown): Government-database markets, global document coverage, the ID types in each, and their capture requirements.
- [NFC chip verification](https://trust.myaza.co/documentation/nfc-chip/markdown): Reading an eMRTD chip (e-passports and chip eID cards), what data is extracted, and how it is authenticated server-side.
- [Business verification quickstart](https://trust.myaza.co/documentation/business-verification-quickstart/markdown): Create a KYB workflow, send a company verification link, and receive its result.
- [Business verification (KYB)](https://trust.myaza.co/documentation/business-verification/markdown): Verify a company against the official registry, plus documents, declarations, and due diligence on its owners.
- [Key people & ownership](https://trust.myaza.co/documentation/key-people/markdown): Due diligence on the people who own or control a business, including corporate shareholders and ownership chains.
- [What Risk Intelligence is](https://trust.myaza.co/documentation/risk-intelligence/markdown): Real-time decisions, ongoing customer monitoring, Travel Rule controls and investigations.
- [Risk Intelligence quickstart](https://trust.myaza.co/documentation/risk-intelligence-quickstart/markdown): Submit your first Sandbox transaction and read its risk decision.
- [Read customer risk](https://trust.myaza.co/documentation/customer-risk-reads/markdown): Read one customer assessment or filter a customer book with consistent risk, monitoring and totals.
- [Risk overview](https://trust.myaza.co/documentation/compliance/markdown): Monitor entities, screen against watchlists, and investigate suspicious activity (FRAML).
- [Link customer identities](https://trust.myaza.co/documentation/identity-hub/markdown): Sync your users as monitored entities and read their risk state, server to server.
- [Customer screening](https://trust.myaza.co/documentation/screening/markdown): Sanctions, PEP, and adverse-media watchlist screening for your entities.
- [Crypto transfers and deposits](https://trust.myaza.co/documentation/crypto-operations/markdown): Review crypto transfers, match deposit observations and maintain your address book.
- [Transaction monitoring](https://trust.myaza.co/documentation/monitoring-events/markdown): Send complete transaction relationships and customer activity for real-time screening and risk decisions.
- [Fraud decision settings](https://trust.myaza.co/documentation/monitoring-rules/markdown): Configure how events are scored, thresholds, money limits, built-in rules, and custom rules.
- [Import past transactions](https://trust.myaza.co/documentation/import-past-transactions/markdown): Preview a historical batch, then submit it through Transaction Monitoring.
- [Ongoing customer monitoring](https://trust.myaza.co/documentation/monitoring-policies/markdown): Configure policy defaults, then manage each customer's monitoring state from their Entity.
- [Fraud rules](https://trust.myaza.co/documentation/transaction-rules/markdown): Decide when supported activities should be allowed, reviewed or blocked.
- [Investigations and reporting](https://trust.myaza.co/documentation/investigations/markdown): Triage alerts, investigate evidence, and file suspicious-activity reports.
- [Measure decision effectiveness](https://trust.myaza.co/documentation/decision-effectiveness/markdown): Connect downstream outcomes to Myaza decisions, measure fraud capture, detect drift, and review controlled tuning recommendations.
- [On-Demand Wallet Screening](https://trust.myaza.co/documentation/wallet-screening/markdown): Check one wallet address, understand its exposure, and act on your rules.
- [Test in simulator](https://trust.myaza.co/documentation/platform-simulator/markdown): Run deterministic Myaza Trust risk stories in the sandbox.
- [Travel Rule overview](https://trust.myaza.co/documentation/travel-rule/markdown): Exchange required transfer information and act on the result.
- [Set up Travel Rule](https://trust.myaza.co/documentation/travel-rule-setup/markdown): Your company, institutions and application.
- [Transfer requirements](https://trust.myaza.co/documentation/travel-rule-policies/markdown): Choose rules, information packages and publication.
- [Create a transfer](https://trust.myaza.co/documentation/travel-rule-transactions/markdown): Send the information you already hold in one request.
- [Supply missing information](https://trust.myaza.co/documentation/travel-rule-information/markdown): Recover incomplete transfers without creating duplicates.
- [Exchange and authorise](https://trust.myaza.co/documentation/travel-rule-execution/markdown): Secure messaging and the customer wallet's execution gate.
- [Receive a transfer](https://trust.myaza.co/documentation/travel-rule-incoming/markdown): Review incoming information and admit a verified deposit.
- [Confirm an outgoing transfer](https://trust.myaza.co/documentation/travel-rule-confirmation/markdown): Report wallet confirmation and track message delivery.
- [Receive Travel Rule updates](https://trust.myaza.co/documentation/travel-rule-webhooks/markdown): Events, current status and safe notification handling.
- [Self-hosted wallets](https://trust.myaza.co/documentation/travel-rule-self-hosted/markdown): Signed control proof and separate address review.
- [Test and troubleshoot](https://trust.myaza.co/documentation/travel-rule-testing/markdown): Exercise information gaps, review and stopped transfers.
- [Authentication](https://trust.myaza.co/documentation/webhook-authentication/markdown): Verify V2 signatures, reject replays and rotate endpoint secrets safely.
- [Verification](https://trust.myaza.co/documentation/webhook-verification/markdown): Handle individual verification lifecycle events and their complete public result contract.
- [Business verification](https://trust.myaza.co/documentation/webhook-business-verification/markdown): Integrate entity, identity, key-person and workflow lifecycle events.
- [Risk Intelligence](https://trust.myaza.co/documentation/webhook-risk-intelligence/markdown): Consume risk assessments, immutable signals, level changes and decisions.
- [Activity decisions](https://trust.myaza.co/documentation/webhook-event-monitoring/markdown): Receive decisions for logins, account changes and other customer activity.
- [Transaction decisions](https://trust.myaza.co/documentation/webhook-transaction-monitoring/markdown): Receive the outcome and next action for an assessed transaction.
- [Screening](https://trust.myaza.co/documentation/webhook-screening/markdown): Handle sanctions, PEP, adverse-media and wallet screening outcomes.
- [Continuous Monitoring](https://trust.myaza.co/documentation/webhook-continuous-monitoring/markdown): Receive monitoring state changes, failures and material customer-risk deltas.
- [Alerts & Investigations](https://trust.myaza.co/documentation/webhook-alerts-cases/markdown): Integrate alert and investigation lifecycle events without exposing analyst evidence.
- [Wallet Intelligence](https://trust.myaza.co/documentation/webhook-wallet-intelligence/markdown): Handle wallet and crypto transaction screening events.
- [Billing](https://trust.myaza.co/documentation/webhook-billing/markdown): Track credit balance changes and API-key lifecycle events.
- [Webhook Testing](https://trust.myaza.co/documentation/webhook-testing/markdown): Test signed deliveries, retries, aliases and idempotency before going live.

## Blog

Articles from the Myaza Trust team: https://trust.myaza.co/blog (RSS: https://trust.myaza.co/blog/rss.xml)

- [How to manage workspace access and costs with Myaza Trust](https://trust.myaza.co/blog/how-to-workspace-operations): Manage team access, environments and cost controls deliberately. Give each teammate the permissions needed for their job and keep Sandbox preparation separate from Production activity. (2026-10-04, by Charles Archibong)
- [How to test and troubleshoot an integration with Myaza Trust](https://trust.myaza.co/blog/how-to-integration-testing): Test the complete integration, including failures and recovery. Choose the supported fixture for the API family you use, then inspect both Myaza’s record and your application’s behaviour. (2026-10-04, by Charles Archibong)
- [How to receive results reliably with Myaza Trust](https://trust.myaza.co/blog/how-to-result-delivery): Receive Myaza results reliably with a signed webhook receiver. Verify the exact bytes, store each event durably and recover retries without repeating the customer action. (2026-10-04, by Charles Archibong)
- [How to connect your customer records with Myaza Trust](https://trust.myaza.co/blog/how-to-customer-book): Connect the customers already in your application to Myaza records using stable references. Retain what you know about their verification source rather than upgrading imported claims into verified facts. (2026-10-04, by Charles Archibong)
- [How to add verification to your app with Myaza Trust](https://trust.myaza.co/blog/how-to-capture-integration): Add verification to your app using a published workflow and a supported SDK or hosted session. Keep capture in the customer journey and final result handling on your backend. (2026-10-04, by Charles Archibong)
- [How to verify a business with Myaza Trust](https://trust.myaza.co/blog/how-to-verify-business): Verify a business against a supported registry and choose the additional evidence your onboarding policy needs. Company existence and authority to represent it are different questions. (2026-10-04, by Charles Archibong)
- [How to check and monitor address presence with Myaza Trust](https://trust.myaza.co/blog/how-to-address-presence): Verify address presence over a supported observation window. Configure capture, native reporting and customer consent together, then distinguish verified, failed and inconclusive evidence. (2026-10-04, by Charles Archibong)
- [How to review existing customer addresses with Myaza Trust](https://trust.myaza.co/blog/how-to-address-triage): Review the address evidence already in your customer book. Upload a permitted CSV, inspect the quote and use the resulting grades to choose the right next capture or presence check. (2026-10-04, by Charles Archibong)
- [How to manage crypto destinations and observations with Myaza Trust](https://trust.myaza.co/blog/how-to-crypto-operations): Keep crypto destination records and deposit observations organised. A deposit observation, customer match, screening decision and settled funds are separate facts. (2026-10-04, by Charles Archibong)
- [How to set up Travel Rule exchange with Myaza Trust](https://trust.myaza.co/blog/how-to-travel-rule): Set up your organisation’s Travel Rule information-exchange journey, test it and follow the displayed activation requirements. Every transfer still needs its own current authorisation before your wallet acts. (2026-10-04, by Charles Archibong)
- [How to screen a crypto wallet with Myaza Trust](https://trust.myaza.co/blog/how-to-wallet-screening): Screen a saved crypto wallet and inspect the decision with its exposure evidence. Keep blockchain risk, address approval, signed control and transfer clearance separate. (2026-10-04, by Charles Archibong)
- [How to measure decision quality with Myaza Trust](https://trust.myaza.co/blog/how-to-decision-quality): Measure decision quality using confirmed downstream outcomes. Review fraud capture and customer friction without silently changing the live policy. (2026-10-04, by Charles Archibong)
- [How to review and investigate findings with Myaza Trust](https://trust.myaza.co/blog/how-to-investigate-findings): Turn a risk alert into owned casework. Review the reason, gather evidence and record a clear outcome that the next team member can understand. (2026-10-04, by Charles Archibong)
- [How to understand customer risk with Myaza Trust](https://trust.myaza.co/blog/how-to-customer-risk): Read customer risk with its evidence and assessment basis. Customer risk helps explain a customer’s recorded state; it is different from the risk decision for a specific payment. (2026-10-04, by Charles Archibong)
- [How to assess transaction risk with Myaza Trust](https://trust.myaza.co/blog/how-to-assess-transactions): Assess transaction risk before your application moves money. Submit an exact amount, the right direction and the parties involved, then use the decision and its explanation. (2026-10-04, by Charles Archibong)
- [How to assess account activity with Myaza Trust](https://trust.myaza.co/blog/how-to-assess-activity): Assess logins, account recovery and other non-payment activity. Send the actual customer and device context, read the returned decision and enforce it in your own app. (2026-10-04, by Charles Archibong)
- [How to keep customer screening up to date with Myaza Trust](https://trust.myaza.co/blog/how-to-monitor-customers): Continuous monitoring rechecks selected customer evidence over time. Configure a policy, enrol eligible customers and give material changes a clear review owner. (2026-10-04, by Charles Archibong)
- [How to screen customers for risk with Myaza Trust](https://trust.myaza.co/blog/how-to-screen-customers): Screen customers for sanctions, politically exposed person and adverse-media findings. Start with a correctly linked customer, run the supported checks, then review possible matches with the evidence available. (2026-10-04, by Charles Archibong)
- [How to investigate connected customers with Myaza Trust](https://trust.myaza.co/blog/how-to-connected-customers): Investigate connections that may explain suspicious activity. Shared devices, instruments and locations help you ask better questions; they do not establish that every connected customer is the same person. (2026-10-04, by Charles Archibong)
- [How to manage reviewed lists with Myaza Trust](https://trust.myaza.co/blog/how-to-review-lists): Use organisation lists to apply reviewed evidence consistently. Keep the decision to add an entry separate from the rules that decide what a list match does. (2026-10-04, by Charles Archibong)
- [How to search for matching customers with Myaza Trust](https://trust.myaza.co/blog/how-to-face-search): Search an authorised face photo against the eligible faces in your organisation. Use this for investigation and review, and keep it distinct from comparing two photos or proving a login. (2026-10-04, by Charles Archibong)
- [How to verify a customer again with Myaza Trust](https://trust.myaza.co/blog/how-to-reverify-customer): Ask an existing applicant to redo a finished verification, either fully or only for selected steps. Re-verification keeps the verification ID and records a new attempt so your team can explain what changed. (2026-10-04, by Charles Archibong)
- [How to compare two faces with Myaza Trust](https://trust.myaza.co/blog/how-to-face-comparison): Compare two face photos when you need a 1:1 similarity verdict. This check is separate from liveness and from searching a customer book. (2026-10-04, by Charles Archibong)
- [How to confirm a returning customer with Myaza Trust](https://trust.myaza.co/blog/how-to-returning-customer): Protect a returning-customer journey with a subject-bound face re-authentication workflow. Compare the current live capture with an eligible enrolment or an authorised reference photo, then let your backend decide whether to continue the login. (2026-10-04, by Charles Archibong)
- [How to confirm address evidence with Myaza Trust](https://trust.myaza.co/blog/how-to-confirm-address): Collect a map pin and the address details your team needs. Address Intelligence corroborates available evidence and explains its strength; a customer’s typed address remains their claim. (2026-10-04, by Charles Archibong)
- [How to collect customer declarations with Myaza Trust](https://trust.myaza.co/blog/how-to-customer-declarations): Collect the declarations your policy needs, such as source of funds or expected activity. A questionnaire gives you recorded customer answers; it does not independently verify those answers. (2026-10-04, by Charles Archibong)
- [How to confirm contact details with Myaza Trust](https://trust.myaza.co/blog/how-to-contact-verification): Verify contact access with an email or phone code. Use the workflow step for capture journeys, or the standalone API when your app needs a separate contact check. (2026-10-04, by Charles Archibong)
- [How to add device intelligence with Myaza Trust](https://trust.myaza.co/blog/how-to-device-intelligence): Device Intelligence adds context from the device and network used during capture. Configure the findings your team cares about and use them with other evidence rather than treating every shared device as fraud. (2026-10-04, by Charles Archibong)
- [How to strengthen identity evidence with Myaza Trust](https://trust.myaza.co/blog/how-to-identity-evidence): NFC verification adds authenticated chip evidence from a supported passport or identity card. Set it up in a mobile capture workflow and understand when the result can, and cannot, raise assurance. (2026-10-04, by Charles Archibong)
- [How to confirm a live person with Myaza Trust](https://trust.myaza.co/blog/how-to-live-person): Liveness helps establish that a real person is in front of the camera. Enable it in the workflow customers use, choose a method, and route captures your policy cannot accept. (2026-10-04, by Charles Archibong)
- [How to verify a new customer with Myaza Trust](https://trust.myaza.co/blog/how-to-verify-customer): Verify a new customer with a published individual workflow. The customer completes the document and selfie journey; your backend receives the outcome and applies your onboarding policy. (2026-10-04, by Charles Archibong)
- [How to detect duplicate customers with Myaza Trust](https://trust.myaza.co/blog/how-to-duplicate-customers): Set up face search in your onboarding workflow, decide what happens when one person uses another account, and check that your app handles the result. (2026-10-04, by Charles Archibong)
- [Myaza Trust joins NVIDIA Inception](https://trust.myaza.co/blog/myaza-trust-joins-nvidia-inception): Matching a face to one document is a contained problem. Searching it against every identity a business has verified is not. Why our fraud work is becoming a compute problem, and why Myaza Trust has joined NVIDIA Inception. (2026-09-29, by Charles Archibong)
- [White-label verification: putting your own logo on every verification screen](https://trust.myaza.co/blog/white-label-verification-branding): You can replace the “Protected by Myaza” footer on every verification screen with your own logo. It costs $0.10 per production verification, and your organisation needs $750 of paid credit the first time a custom logo goes live. After that, anyone on your team can change it at any balance. (2026-09-28, by Charles Archibong)
- [Perpetual KYC: keeping customer records current without re-onboarding everyone](https://trust.myaza.co/blog/perpetual-kyc): Perpetual KYC means refreshing a customer's record when something changes, not re-checking everyone on a calendar. The FATF asks that CDD data be kept up to date, particularly for higher-risk customers; events and risk decide when and how much you ask for. (2026-09-27, by Charles Archibong)
- [Screening crypto wallet addresses: what it catches and where it stops](https://trust.myaza.co/blog/crypto-wallet-screening): Wallet screening catches addresses that a sanctions authority has published, matched exactly. It misses unlisted addresses controlled by the same person, funds that passed through intermediaries, and anything published after your last check. (2026-09-27, by Charles Archibong)
- [PEP screening: what a match means and what to do next](https://trust.myaza.co/blog/pep-screening-what-a-match-means): A PEP match means you must confirm the person and classify them, not refuse them. Foreign PEPs always need senior management approval, source of wealth and funds, and enhanced monitoring; domestic PEPs need it only when your risk assessment says the relationship is higher risk. (2026-09-27, by Charles Archibong)
- [Cutting sanctions screening false positives without missing real matches](https://trust.myaza.co/blog/reducing-sanctions-false-positives): Most sanctions false positives come from thin customer data, not oversensitive matching. Screen with verified date of birth, nationality and ID numbers, record why each match was cleared so it does not return, and leave fuzzy matching alone. (2026-09-27, by Charles Archibong)
- [FATF's payment transparency changes: what payment firms should prepare for](https://trust.myaza.co/blog/fatf-payment-transparency-changes): In June 2025 the FATF revised Recommendation 16: standard originator and beneficiary data above USD/EUR 1,000, a defined start to the payment chain and new checks against misdirected payments. Countries are expected to implement by the end of 2030. (2026-09-27, by Charles Archibong)
- [The Travel Rule explained for teams launching crypto transfers](https://trust.myaza.co/blog/travel-rule-explained): The Travel Rule requires the sending VASP to collect originator and beneficiary information, pass it to the receiving VASP immediately and securely, and make it available to authorities. The hard parts are finding the counterparty, handling self-hosted wallets and jurisdictions that disagree. (2026-09-27, by Charles Archibong)
- [FATF's 2026 virtual assets update: what VASP compliance teams should take from it](https://trust.myaza.co/blog/fatf-virtual-assets-update-2026): The FATF's seventh targeted update, published 16 July 2026, finds most jurisdictions now have Travel Rule laws but few enforce them, and asks VASPs to strengthen wallet screening, unhosted-wallet due diligence and scrutiny of offshore platforms. (2026-09-27, by Charles Archibong)
- [FATF's June 2026 grey list: what it means for onboarding in affected markets](https://trust.myaza.co/blog/fatf-grey-list-june-2026): On 19 June 2026 the FATF added Bosnia and Herzegovina and Iraq to its grey list and removed Algeria and Namibia. A grey listing is a risk factor to weigh, not an instruction to apply enhanced due diligence or to exit a market. (2026-09-27, by Charles Archibong)
- [Where verification flows lose people, and how to fix each step](https://trust.myaza.co/blog/reducing-verification-drop-off): People abandon verification at predictable moments: an unexplained start, the camera permission prompt, document capture, the desktop that has no camera, and being asked to redo everything after one failure. Measure abandonment per step, then fix the step, not the whole flow. (2026-09-27, by Charles Archibong)
- [When one ID is not enough: verifying two or three IDs in one run](https://trust.myaza.co/blog/multi-id-verification): Ask for more than one ID when a single ID's weakness is exactly your risk, and choose IDs that come from independent sources. Then set the pass policy (all, at least two, or any one) by asking what you would accept if one check could not confirm. (2026-09-27, by Charles Archibong)
- [Age checks that hold up: from a birthday field to a verified date of birth](https://trust.myaza.co/blog/age-verification-from-government-id): A reliable age check uses a date of birth established by an identity check (the government record, the document or its chip), compares it with a per-country limit, and fails closed when no date can be read. A typed birthday proves nothing, and a face gives an estimate with a margin of error. (2026-09-27, by Charles Archibong)
- [Verifying addresses where streets have no numbers](https://trust.myaza.co/blog/verifying-addresses-without-street-numbers): Where streets have no numbers, stop matching address strings. Capture a location (a map pin with the applicant's own directions and details), then corroborate it at the level of the area against independent records, and grade how strongly it is supported. (2026-09-27, by Charles Archibong)
- [Proof of address: what a utility bill does and does not prove](https://trust.myaza.co/blog/proof-of-address-documents): A proof-of-address document shows that an address was printed on a document, often with a name, at a date. Give it the weight of corroborating evidence, not verification, and set rules for name, recency and document type that fit each market. (2026-09-27, by Charles Archibong)
- [Proving the person applying can act for the business](https://trust.myaza.co/blog/verifying-kyb-applicant): Registration numbers are public, so anyone can type a real company's number. To know the applicant represents the business, verify who they are, check them against the officers the register names, and, where they are not named, ask for evidence of their authority. (2026-09-27, by Charles Archibong)
- [When the owner is another company: handling layered ownership in KYB](https://trust.myaza.co/blog/layered-company-ownership): A corporate shareholder is never the beneficial owner; it is a branch of the ownership chain you have not finished. Screen it as an entity, multiply stakes down the chain to find effective ownership, trace the branches that can matter, and escalate the ones you cannot resolve. (2026-09-27, by Charles Archibong)
- [Finding the people behind a company: a practical guide to beneficial ownership](https://trust.myaza.co/blog/beneficial-ownership-checks): Identify beneficial owners by reconciling two imperfect lists, the register and the applicant's own disclosure, then testing each person against an ownership threshold and, where nobody crosses it, against control by other means. Verify each person to a depth set by their role. (2026-09-27, by Charles Archibong)
- [What a business registry check tells you, and what it leaves out](https://trust.myaza.co/blog/business-registry-verification): A registry lookup confirms that a company with that number exists and shows what it last filed. It does not prove the applicant represents it, who really owns it, or that it trades as it says. Each gap needs its own check. (2026-09-27, by Charles Archibong)
- [Not every pass is equal: using assurance levels in onboarding decisions](https://trust.myaza.co/blog/kyc-assurance-levels): A chip pass, a government database pass and a document-only pass are different strengths of evidence. Decide in advance what each tier may do, route on the tier together with the photo the face was matched against, and let customers move up a tier rather than failing them. (2026-09-27, by Charles Archibong)
- [Setting a face-match threshold without guessing](https://trust.myaza.co/blog/setting-face-match-thresholds): A face-match threshold is a policy choice between wrongly accepting impostors and wrongly rejecting real customers. Set the pass mark from labelled pairs of your own traffic, add a bounded review band just below it, and revisit both as your users and cameras change. (2026-09-27, by Charles Archibong)
- [What reading an ePassport chip proves, and what it can't](https://trust.myaza.co/blog/epassport-nfc-chip-verification): Reading an ePassport chip can prove the data was signed by the issuing state and has not been altered, and with Active Authentication that the chip is not a copy. It cannot prove the person holding the passport is its owner; only a face match against the chip photo does that. (2026-09-27, by Charles Archibong)
- [Why a liveness result from the phone is not enough](https://trust.myaza.co/blog/server-side-liveness-verification): A liveness result produced on the phone is a claim made by a device the attacker may control. Treat it as input, keep the recorded evidence, and re-check that evidence on the server before the result counts. (2026-09-27, by Charles Archibong)
- [Gesture or screen-flash liveness: choosing the right challenge](https://trust.myaza.co/blog/gesture-vs-flash-liveness): Gesture challenges suit broad consumer populations and defeat photos and pre-recorded video. Screen-flash challenges add a random colour sequence that a replayed or injected video cannot contain. Use both where the account is valuable enough to justify the extra seconds. (2026-09-27, by Charles Archibong)
- [NIN and BVN checks in Nigeria: what each one proves](https://trust.myaza.co/blog/nin-bvn-verification-nigeria): A NIN check confirms a national identity recorded by NIMC; a BVN check confirms an identity enrolled in the Nigerian banking system; a vNIN is a privacy-preserving token for a NIN. Each proves the record exists, and only a live selfie matched to the record photo proves the applicant owns it. (2026-09-27, by Charles Archibong)
- [Document checks or government database checks: which does your onboarding need?](https://trust.myaza.co/blog/document-vs-government-database-checks): Reading a document tells you it looks genuine; checking the government record tells you the identity was issued. Use the record wherever one exists, and remember that neither proves the applicant owns the identity until a live face is matched to a trusted photo. (2026-09-27, by Charles Archibong)
- [What identity verification actually checks, and what it doesn't](https://trust.myaza.co/blog/what-identity-verification-checks): A KYC check proves three narrow things at one moment: the identity exists, the evidence for it is genuine, and the person in front of the camera is its owner. It says nothing about intent, and it starts ageing the day it passes. (2026-09-27, by Charles Archibong)
- [Sending events for real-time risk scoring: an integration guide](https://trust.myaza.co/blog/sending-events-for-real-time-risk-scoring): Call the transactions endpoint for money movement and the activities endpoint for logins and account changes, from your backend, before you act. Send complete parties and stable IDs, then route on the summary outcome: allow, review or block. (2026-09-27, by Charles Archibong)
- [Adding identity verification to a React Native or Flutter app](https://trust.myaza.co/blog/mobile-identity-verification-react-native-flutter): The component call is the easy part. A mobile integration is mostly native build setup, camera permission, mounting a dashboard workflow so changes skip the app store, and keeping results on your server rather than on the phone. (2026-09-27, by Charles Archibong)
- [Mapping verification statuses to your product's states](https://trust.myaza.co/blog/mapping-verification-statuses): Drive your product from status, the outcome, and store checkStatus beside it as the explanation. Map each of the ten status values to one state in your own system, and take the latest status from verification.status_updated or polling. (2026-09-27, by Charles Archibong)
- [Idempotent verification requests: avoiding duplicate checks and duplicate charges](https://trust.myaza.co/blog/idempotent-verification-requests): Give every logical verification one requestId, save it before you send the request, and reuse it on every retry. A repeated requestId returns the existing verification instead of creating and charging a second one. (2026-09-27, by Charles Archibong)
- [Publishable and secret keys: keeping verification data off the client](https://trust.myaza.co/blog/publishable-and-secret-api-keys): Put the publishable key in your app and keep the secret key on your server. A publishable key can start a verification and read minimal status, never identity data, so plan for it to leak and limit what a leak costs. (2026-09-27, by Charles Archibong)
- [Testing a verification integration end to end in sandbox](https://trust.myaza.co/blog/testing-verification-in-sandbox): Use the published sandbox test IDs, whose last digits pick the outcome, to drive every result your code must handle, then test your webhook receiver with signed simulated events before switching to live keys. (2026-09-27, by Charles Archibong)
- [Changing a verification flow without shipping an app release](https://trust.myaza.co/blog/changing-verification-flows-without-a-release): Mount the SDK with a workflow ID and the flow's configuration is fetched from the server on each verification. Re-publishing changes the steps, checks, copy and decision rules for the next verification, with no app release. (2026-09-27, by Charles Archibong)
- [How decision graphs turn checks into approve, review or decline](https://trust.myaza.co/blog/decision-graphs-explained): When a verification finishes, the workflow's decision graph gathers the results, walks branches over a closed set of fields, and lands on approve, review or decline. The outcome sets the customer's disposition without rewriting what the checks found. (2026-09-27, by Charles Archibong)
- [Designing your product around asynchronous verification results](https://trust.myaza.co/blog/designing-for-asynchronous-verification): Treat submission as the start of a state machine, not the end of a request. Show a pending state keyed on the verification ID, update it from webhooks, and let the status change more than once. (2026-09-27, by Charles Archibong)
- [Verifying webhook signatures and handling retries correctly](https://trust.myaza.co/blog/verifying-webhook-signatures): Verify the V2 signature over the raw request bytes, reject timestamps outside the replay window, record the event ID under a unique constraint before doing any work, and return 2xx only once the event is durably stored. (2026-09-27, by Charles Archibong)
- [SDK embed or hosted link: choosing how to integrate verification](https://trust.myaza.co/blog/sdk-or-hosted-link): Embed the SDK when verification happens inside your product; send a per-applicant hosted link when it happens outside it. Either way, run a published workflow so the choice is about delivery, not about the flow. (2026-09-27, by Charles Archibong)
- [Handling biometric data under African data protection laws](https://trust.myaza.co/blog/biometric-data-protection-africa): All three laws treat biometric data as a special category. Nigeria names facial images and limits sensitive data to listed grounds, Kenya treats biometric processing as high risk, and POPIA prohibits it unless an authorisation applies. Plan a lawful ground, a DPIA and minimisation. (2026-09-27, by Charles Archibong)
- [What device and IP signals can and cannot tell you](https://trust.myaza.co/blog/device-and-ip-signals-limits): Device and IP signals describe the handset and connection, not the person. Emulators and datacentre IPs are strong warnings; shared devices, IP velocity and IP location are weak. Use them as corroboration, and trust IP location at country level only. (2026-09-27, by Charles Archibong)
- [Account takeover: step up the challenge instead of blocking the customer](https://trust.myaza.co/blog/account-takeover-step-up): When a login looks like account takeover, do not guess. Let the session continue with limited rights, and ask for proof that only the verified person can give, such as a fresh selfie matched to their enrolment, before any payout, beneficiary change or password reset goes through. (2026-09-27, by Charles Archibong)
- [Finding the same person behind many accounts](https://trust.myaza.co/blog/finding-duplicate-accounts): Rank shared artefacts by what they prove. A repeated verified ID number means the same person. A repeated face is strong evidence for review. A shared device, phone or address is common in families, so treat it as corroboration and count distinct people before acting. (2026-09-27, by Charles Archibong)
- [Deepfakes and injected camera feeds: how identity checks are attacked](https://trust.myaza.co/blog/deepfakes-and-injection-attacks): Attackers either hold fake media up to a real camera (a presentation attack) or feed it straight into the data stream (an injection attack). Each needs its own defence, and the strongest checks add evidence a camera cannot supply. (2026-09-27, by Charles Archibong)
- [Preparing customer due diligence for the EU AML Regulation](https://trust.myaza.co/blog/eu-aml-regulation-2027-readiness): The EU AML Regulation applies directly from 10 July 2027 and replaces national CDD rules with one text. Build to the Regulation now: its data list, verification routes, 25% ownership test and refresh ceilings are fixed, while AMLA's detailed CDD standards were still in draft as of September 2026. (2026-09-27, by Charles Archibong)
- [Companies House ID verification: the November 2026 deadline and what KYB teams will see](https://trust.myaza.co/blog/companies-house-identity-verification-deadline): Since 18 November 2025, new UK directors and PSCs must verify their identity with Companies House, and existing ones within a 12-month transition to mid-November 2026. It adds register signals for KYB teams, but does not show that the person applying to you is that director. (2026-09-27, by Charles Archibong)
- [CBN's 2026 BVN framework changes: what onboarding teams should note](https://trust.myaza.co/blog/cbn-bvn-framework-changes-2026): From 1 May 2026, under a CBN circular dated 12 March 2026, only adults can enrol for a BVN, the linked phone number can change only once, banks must hold BVNs tied to suspicious transactions on a 24-hour watchlist, and database access is limited to licensed institutions. (2026-09-27, by Charles Archibong)
- [CBN's baseline standards for automated AML: preparing your stack](https://trust.myaza.co/blog/cbn-automated-aml-baseline-standards): The CBN's baseline standards, issued on 10 March 2026, set mandatory minimum requirements for automated systems that detect, analyse and report suspicious activity in real time. The CBN has said compliance is assessed at the level of the institution, so buying a tool is a start, not an answer. (2026-09-27, by Charles Archibong)
- [goAML explained: how reports reach financial intelligence units](https://trust.myaza.co/blog/goaml-reporting-explained): goAML is software built by the UN Office on Drugs and Crime for financial intelligence units. Reporting entities register on their FIU's goAML portal and submit reports by web form or as XML files that follow the goAML schema, using the FIU's own codes. (2026-09-27, by Charles Archibong)
- [Writing a suspicious activity report an FIU can act on](https://trust.myaza.co/blog/writing-a-suspicious-activity-report): A useful SAR or STR narrative answers who, what, when, where, why and how in one chronological account, explains why the activity is unusual for this customer, and gives facts an analyst can follow without opening your systems. (2026-09-27, by Charles Archibong)
- [From alert to decision: running an investigation queue that keeps up](https://trust.myaza.co/blog/alert-triage-and-case-management): Keep two queues with two jobs. Triage alerts quickly and label every one; open an investigation only when the evidence needs an owner, group it by customer, prioritise by risk and deadline, and close it with a recorded outcome and rationale. (2026-09-27, by Charles Archibong)
- [Backtest before you switch on: testing monitoring rule changes safely](https://trust.myaza.co/blog/backtesting-monitoring-rules): Replay recent scored events through the proposed configuration, then read each decision that would change as well as the count. A backtest shows what a change would have done to the past; your written expectation is what tells you whether that is the right result. (2026-09-27, by Charles Archibong)
- [Transaction monitoring rules that find risk instead of noise](https://trust.myaza.co/blog/transaction-monitoring-rules): A monitoring rule earns its place when it maps to a risk you actually carry, fires on data you actually send, and produces alerts an analyst can close with a reason. Tune rules against labelled outcomes, never against alert counts alone. (2026-09-27, by Charles Archibong)