How to collect customer declarations with Myaza Trust
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.
Charles Archibong, Co-founder
· 4 min read
Key takeaways
- Every required question is answerable on mobile.
- Optional unanswered questions do not masquerade as negative findings.
- Rules use the actual recorded answer type.
- A refresh attaches to the intended existing customer reference.
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.
Before you begin
Required questions and a review policy
Customer consent
Use a team member with permission for this control. Check the organisation and environment before changing a setting. Review the current price before a paid check or ongoing enrolment. Screenshots show an example workspace or the public integration reference; they do not show a real customer or a completed paid check.
Set up and use the capability
Step 1: Choose the right workflow scope
Open Configuration → Workflows in Sandbox. Use an existing full verification workflow when declarations belong in onboarding. For a periodic refresh, choose the Declarations refresh template with the questionnaire scope. Scoped submissions attach to the existing customer reference and do not replace the customer’s KYC status. Scope can be edited before the first publication; afterwards use a scoped copy for a different scope.
Dashboard example: Choose the right workflow scope
Step 2: Open the Questionnaire step
Enable Questionnaire and select it in the step list. Open Setup. A workflow with no questions skips the step entirely, so an enabled heading alone does not collect declarations. Select Add from library for a provided question or Custom question for your own. Write the question in words the customer can answer without interpreting your internal risk terminology.
Dashboard example: Open the Questionnaire step
Step 3: Give each question a stable purpose
Set the offered answer type and choices for the question. Keep its key stable when your integration or rules use it. Require only answers your policy actually needs and test the customer preview for clarity. If you map a question to a canonical profile field, understand that mapping first; for example, a wallet-address answer can append a claimed wallet to the entity’s set and enrol wallet screening.
Integration reference: Capture add-ons
Step 4: Route the answers with explicit rules
Review Rules and your decision graph. Use the documented questionnaire.<key> field for the exact question. Test a material answer, a permitted answer and a missing answer where optional. Keep a human review route when an answer needs explanation. Do not treat a declaration that says “verified” as independent verification or assume every collected answer changes a decision.
Integration reference: Decisioning
Step 5: Save and publish the workflow
Wait for Saved in the editor. Select Publish, or Publish changes for an existing workflow. In the publication review, check the target environment, workflow ID, price and readiness warnings. Resolve blocking issues, then confirm Publish version. A saved draft is not the version customers use. New sessions use the new published snapshot; sessions already created retain their original version.
Dashboard example: Save and publish the workflow
Step 6: Connect the published workflow to your app
Copy the workflow ID. Give that ID to your supported Web, React Native or Flutter SDK, with a publishable key from the same organisation and environment and a stable customer reference. Alternatively, create a customer-bound hosted session on your backend with POST /api/kyc/sessions, using a secret key. Return the session URL only to the intended customer. A camera preview does not run a verification or prove your backend handles the result.
Integration reference: Request
Step 7: Read the final outcome on your backend
After capture, store the verification ID against your own customer reference. Follow status updates or retrieve current status. Read status for the outcome and checkStatus, reason and reasonCode for the explanation. When a workflow has decision rules, a checks-completed event can arrive before the final workflow decision. Keep processing and human-review results pending; do not approve an account merely because the customer finished the camera screens.
Integration reference: Status and checkStatus
Get more from the capability
Use a declarations-refresh workflow for changes over time instead of asking customers to repeat all identity capture.
Keep question keys and choices consistent with your backend’s interpretation. Treat wording changes that alter meaning as a versioned policy change.
Review unexpected answers with customer context; use them as claims until corroborated by other evidence.
Test before relying on it
Run the supported Sandbox or simulator scenarios for this product. Where a tool is Production only, check access and scope first, then use only a permitted, deliberately reviewed Production test. A documentation screenshot or a successful page load is not an end-to-end integration test.
Every required question is answerable on mobile.
Optional unanswered questions do not masquerade as negative findings.
Rules use the actual recorded answer type.
A refresh attaches to the intended existing customer reference.
Troubleshooting
No questionnaire screen appears
Check that the step has at least one saved question and that the workflow version is published.
A rule never matches
Check the question key, answer type and rule order against the actual returned answer.
Refreshing declarations changed my expectations of KYC
The scoped flow records declarations; it does not make a new full identity-verification decision.
Open the setup and integration references
Read the integration reference
Back to Solutions. Choose the capability you want to activate, then follow its own guide.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
