Adaptive MFA

Multi-Factor Authentication

If a user receives an "Obligation" policy decision, this means their device was not trusted, or there were too many risky signals to authenticate the user without further verification. You can look the transaction up in the AXN Admin console to see why they received a specific decision, as outlined here: Transaction Report

  • In this case, it's time to challenge the user with MFA. Your user interface should present a choice based on the types of MFA you want to support.
  • For this example, let's assume the user chose the SMS pincode option.
  • Your system should prefill an approved phone number into the UI.
  • Once ready, your system should call the /otp API (step 3A in the Postman Project.)



  • Replace the bearer token with the same one you've used in previous steps.
    • Replace the ASI with the previous API call's `transaction_id", as outlined here Using API for a multi-step Workflow
    • Ensure the credential is the same as the previous steps.
    • The number included is the test data phone number. If you'd like to switch to real data, speak to your Solutions Architect.

If the PIN Code was successfully sent, you will receive an HTTP 200 response:


As a next step, your system will verify the user's PIN was correct, thus proving MFA credential possession.

Verifying the PIN Code to prove device possession

In this step, your UI should collect the 6 digit PIN code sent to the end user. Once submitted, your application should call the ID DataWeb /slverify API to validate the PIN was correct. Use step 4A in the Postman project.




  • Replace the bearer token with the same one you've used in previous steps.

If the PIN was successfully verified, you will receive a policyDecison of "approve". This indicates that the user successfully completed MFA, proving they are the real account holder.


What’s Next

Next up - Trust your user's device after they've successfully passed MFA. This will eliminate them from being challenged again in the future.