User

Definition
This is a user of Swan - an actual person. Swan requires each user of our platform to have a unique and valid phone number. We made this choice because it allows us to offer a much simplified user experience.
Swan is login-less, so users don't have to remember anything; similar to Whatsapp. When it comes to sensitive transactions, our web Strong Customer Authentication gets users' consent and lets Swan verify their identity when necessary (like when they want to make a large transfer).
Authentication
You must perform authentication when a user wishes to access their data (for example by logging into their web banking) or to make transactions through your service, via our API.
Swan's API for user authentication is based on the technology oAuth2 OpenIDConnect. Learn More​
A connected user's data is available at the root of the user query.
User login process
Logging into Swan is easy, but the very first time a user logs in differs from subsequent logins. Here's what the user experience is like after clicking the oAuth URL:
1.The user enters their phone number. This step can be bypassed if you already have this info. Learn more​
If onboarding via a mobile phone: a verification code will be sent by sms to confirm the phone number
If onboarding via a desktop: a link will be sent by sms to confirm the phone number and subsequently open up the verification process on the smartphone
2.The user enters some personal data: first name, last name, and birthdate. This step can be bypassed if you already have this info. Learn more​
3.The user selects a 6-digit passcode that will be used each time user consent is required. If available on the device, the user can also set up TouchID / FaceID for future consents.
4.The user performs identity verification: a combination of identity documentation and biometric face recognition. This step can be performed later.
5.Then the user can start using Swan!
#nocode: they are redirected to your white-labeled web banking, and can start using our services.
by API: they are redirected to the redirectUrl that you specified when you created the oAuth link. 
This will have the codeaccessToken for your customer. Learn more. Careful, if a redirectUrl is specified, it must be declared in the list of possible Redirect URLs in the API Credentials tab on the dashboard.
Any subsequent logins will go even quicker: the user will simply confirm their phone number, enter their 6-digit passcode or use biometry, and then they're in!
If the user configured TouchID / FaceID, every time they log in or consent to a sensitive operation on the same device, it will be through their fingerprint or face scan. Here's the list of the supported browsers: https://caniuse.com/webauthn.
Only if they switch to another device will we ask them for their 6-digit passcode.
Identity Verification
Sometimes, a user of Swan must prove their identity. For this purpose, Swan provides secure identity verification that uses streaming live-video and A.I. technology.
The identity verification can be performed 24/7 within a 10-minute timeframe, and includes the following validations:
Is the ID document authentic?
Is this person real?
Does the face presented actually match the ID document?
During the verification process, the user has to login for security reasons.
Identity verification of a physical person is the first step in the verification of an account holder. Learn More​
Identity verification can be removed for some B2B cases only with agreement by our compliance department. This is only possible for users that have non-sensitive access to an account. Learn more​
Identification Level
Swan supports different identification levels depending on the user's use case and the same user can be verified with multiple identification levels.
The list of identificationLevels is accessible in the userquery.
IdentificationLevels impact on identificationStatus State
Expert
This is the default identification level at Swan used to verify some account holders' legal representatives and every account membership with sensitive access to an account. This requires a manual asynchronous review by an expert.
To start the identification, the user must be redirected to an oauth2 authorization code process with the query parameter identificationLevel=Expert
Qualified Electronic Signature (QES)
A Qualified Electronic Signature is an electronic signature that is compliant with EU Regulation No 910/2014 (eIDAS Regulation) for electronic transactions within Europe. It enables to verification of the authorship of a declaration in electronic data exchange over long periods of time. Qualified Electronic Signatures can be considered as a digital equivalent to handwritten signatures.
This identification level is mostly used at Swan to verify individual account holders and requires a manual asynchronous review by an expert before starting the signature. The process follows a two-step flow:
To start the identification, the user must be redirected to an oauth2 authorization code process with the query parameter identificationLevel=QES
Once this verification is done, the user's  identificationStatus switches to ReadyToSign
You can now reengage the user to sign our terms and conditions in order to complete their identification by redirecting them to an oauth2 authorization code process with the query parameter identificationLevel=QES
Identification Status
identificationStatus is accessible in the userquery. It helps you follow the status of the last identification process. Use this to find out precisely what went wrong when a user was unable to be verified.
You should ask the user to verify their identity only if the identificationStatus is not Processing or ValidIdentity.
Once the identification status is ValidIdentity,  unless the user reinitializes their smartphone browser, they will never again have to prove their identity with Swan for the given identification level.
Each time the identification status changes to ValidIdentity or InsufficientDocumentQuality or InvalidIdentity or ReadyToSign, the user receives a text message.
Sandbox Users
To make your integration with Swan as seamless as possible, we allow you to create as many Sandbox users as you want from Swan. Sandbox users make it possible to simulate the different processes you may encounter with your real users, once you go live. You can simulate different onboarding scenarios and processes, or practice managing the user rights of your accounts.
When you add members to your project on the dashboard, they have access to the menu Sandbox Users. By default, you have a first Sandbox user: Jane Doe. It is easy to add, modify, or delete Sandbox users from this tab.
Here are the settings you can modify for each Sandbox user:
First Name
Last Name
Birthdate
Nationality
Identification status: lets you simulate all the states during the identity verification process. Learn more​
Identification levels: lets you simulate all the levels. Learn more​
If one of the identification levels is selected, the sandbox is considered verified regardless of the identification status 
Auto consent: saves you considerable time during the development phase, by automatically allowing consent, removing the need to repeatedly get consent.
When you are playing in the Sandbox environment - using Swan API, simulating the onboarding of a new account holder, accessing web banking - the user being employed is the one selected in the dashboard. To change users, just select a different one.
Last modified 1mo ago