Phone numbers in Sandbox vs Prod

I have noticed some behavior in the Sandbox that I would like clarification on.

Adding a phone number as a 2FA social sub document does not impact the status of the phone number social sub document.

Steps to observe this behavior:

  1. Create a User with an invalid phone number in the base document
  2. PATCH User with a new social sub document of type of “PHONE_NUMBER_2FA” and the identical phone number as step 1.
  3. PATCH User again with a valid mfa_answer to complete the registration
  4. Response from step 3 shows
    a. Social sub document of type “PHONE_NUMBER_2FA” is “REVIEWING|VALID”
    b. Social sub document of type “PHONE_NUMBER” is “SUBMITTED|INVALID”

Questions:

  1. Is there any referential integrity between the PHONE_NUMBER sub document and the PHONE_NUMBER_2FA sub document?
  2. How do we validate a PHONE_NUMBER sub document once it is invalid?

The user’s phone_number array (used for fingerprint registration) is not automatically updated after adding a valid 2FA phone number.

Steps to observe this behavior:

  1. PATCH User with a new sub document with a document type of “PHONE_NUMBER_2FA”
  2. Response from step 1
    a. Social sub document of type “PHONE_NUMBER_2FA” is “REVIEWING”/”MFA_PENDING”
  3. PATCH User with social sub document
    a. Document type and value match social document in step 2
    b. Includes valid “mfa_answer”
  4. Response from step 3
    a. Social sub document of type “PHONE_NUMBER_2FA” is “REVIEWING”/”VALID”
    b. User “phone_number” array does not show the newly verified number
  5. POST to OAuth User with new fingerprint to register
  6. Response from step 5 does not include the newly verified phone number

Question:

  1. Should adding a valid 2FA phone number automatically modify the phone numbers available to perform a 2FA process during a fingerprint registration.

Manually adding an invalid phone number as a 2FA social doc does not prevent it from being used in the fingerprint registration flow.

Steps to observe this behavior:

  1. PATCH User with social sub document of type “PHONE_NUMBER_2FA”
  2. PATCH User with social sub document that includes an invalid “mfa_answer”
  3. Response from step 3 shows the document of type “PHONE_NUMBER_2FA” is “REVIEWING”/”INVALID”
  4. PATCH User’s “phone_number” array with the invalid phone number from steps 1 & 2
  5. Response from step 4 is a 200 and the User’s “phone_number” array now contains the invalid phone number
  6. POST to OAuth User with new fingerprint to start registration
  7. Response from step 6 includes the invalid phone number in the array
  8. POST to OAuth User with new fingerprint, specifying the invalid phone number as the “phone_number” in the body
  9. Response from step 8 is the expected 202

Questions:

  1. Is there any referential integrity between the PHONE_NUMBER_2FA sub document and the User’s phone_number array?
  2. Is there any validation during a fingerprint registration (MFA) flow?

Is there any referential integrity between the PHONE_NUMBER sub document and the PHONE_NUMBER_2FA sub document?

  • No, the PHONE_NUMBER and PHONE_NUMBER_2FA are two different fields set for the user. However, you can set controls for the user so that one of these fields must be valid in order for the user to be verified.

How do we validate a PHONE_NUMBER sub document once it is invalid?

  • It is not possible to validate a PHONE_NUMBER sub document but controls can be set to fall back on PHONE_NUMBER_2FA if PHONE_NUMBER document returns invalid.

Should adding a valid 2FA phone number automatically modify the phone numbers available to perform a 2FA process during a fingerprint registration?

  • No, there are separate processes for adding a valid 2FA phone number that do not automatically add the number used during a fingerprint registration. In order to add the phone number to be used during a fingerprint registration, a separate API call would need to be made.

Is there any referential integrity between the PHONE_NUMBER_2FA sub document and the User’s phone_number array

  • No, there is no referential integrity between the PHONE_NUMBER_2FA and the user’s phone_number array.

Is there any validation during a fingerprint registration (MFA) flow?

  • No, there is no check if the phone number is valid during a fingerprint registration flow. It will attempt to send a validation pin regardless of the document status.

– Matthew, Integration Engineer @ Synapse

Thank you for the information. I have a few followup questions.

  1. In your responses to the first 2 questions you say: “set controls for the user” & “controls can be set”. What do you mean by “controls”? Are these settings in the environment configuration that Synapse maintains, or are they settings in the client dashboard, or simply handling the situations within the code?

1.a) If the “controls” you refer to is for us to handle it within the code, is there a way to change a users status through code?

  1. Will we see the same behavior described in my three scenarios in the production environment?

In your responses to the first 2 questions you say: “set controls for the user” & “controls can be set”. What do you mean by “controls”? Are these settings in the environment configuration that Synapse maintains, or are they settings in the client dashboard, or simply handling the situations within the code?

  • The first option you specified is the correct one. Controls are the settings in the environment configuration (i.e. the platform-specific customizations for how your sandbox and production environments can use the Synapse API), and are maintained by Synapse. In the previous example, when I referred to the ability to “set controls for the user,” I meant that platform controls could be set to require end-users to either have a valid [phone num] or [2fa phone number var].

If the “controls” you refer to is for us to handle it within the code, is there a way to change a users status through code?

  • The controls are not handled directly by you; they are set and maintained by Synapse based on the nature of your use case. If you have reason to believe that your controls are not properly set (i.e. your sandbox is not properly configured for your use case) and you would like to explore the possibility of adjusting these controls, please reach out to your Platform Architect. KYC is verified through our internal KYC verification process, but you can change the user’s permissions to LOCKED, CLOSED, or MAKE-IT-GO-AWAY through an API call. Here are the docs on how to do this https://docs.synapsefi.com/reference#remove-user.

Will we see the same behavior described in my three scenarios in the production environment?

  • Yes, the behavior in Sandbox will translate to production.

Thank you for your reply. I have an additional question specifically around behavior seen in the Sandbox versus what we’ve seen in Production.

Steps to reproduce:

  1. Create a new user with an invalid phone number in the base document
  2. Patch in all remaining required KYC documents, making sure they are all valid
  3. Get the user

Results:
Sandbox: User permission is set to “SEND-AND-RECEIVE”
Production: User permission remains “UNVERIFIED”

Is this behavior something that is also controlled by a platform-specific customization? Or is there a different way to align these behaviors?

The reason for the apparent discrepancy is because any test documents in sandbox do not go through any KYC verification, so any string can be submitted for PHONE_NUMBER in sandbox and will be considered valid by default (except for 541-754-3010 , the sandbox test value for an invalid phone number).

Further insight into variance between sandbox and production environment:
It is possible for production and sandbox platform-specific controls to be set differently (e.g. in this instance you contacted a Platform Architect to adjust sandbox controls related to the PHONE_NUMBER and PHONE_NUMBER_2FA sub-documents in alignment with your production controls).

For general details about how Synapse evaluates KYC and sets user permissions, please refer to the KYC section of our Docs site. In that section we also provide quick reference tables for user permissions and sub-document statuses.