Strong Customer Authentication

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude
• Connect to Cursor

  Install MCP server on Cursor
• Connect to VS Code

  Install MCP server on VS Code

Introduction

Strong Customer Authentication (SCA) is a regulatory requirement imposed by the PSD2 guidelines on all payment service providers in the European Economic Area (EEA).

PSD2 mandates multi-factor authentication (MFA) to reduce fraud and secure online payments. SCA requires at least two of the following three factors:

• Knowledge (Something you know): Password, PIN, security question.
• Possession (Something you have): Smartphone, hardware token, paired device.
• Inherence (Something you are): Fingerprint, FaceID, voiceprint.

When is SCA required?

You must implement SCA for the following scenarios:

1. Login (Access to Account)

According to PSD2, you must enforce 2FA when the customer logs in. You must also re-authenticate the customer via SCA in the following specific scenarios:

• Accessing the account online for the first time.
• Accessing the account balance without disclosing sensitive payment data.
• Accessing transaction records executed in the last 90 days.
• Accessing transaction records older than 90 days.
• Every 180 days since the last time the customer was authenticated using SCA.

2. Sensitive Data Changes

Any modification to customer data (e.g., changing an address, updating a mobile number) requires 2FA to prevent account takeover fraud.

3. Transaction Authorization

Initiating payments or transfers requires SCA to ensure the customer explicitly authorized the movement of funds.

Authentication methods & Platform strategy

Solaris offers two methods for 2FA. You must choose the correct method based on your platform.

1. SMS OTP (Web)

Solaris sends a 6-digit code via SMS to the customer's verified mobile number.

• Target Platform: Web Applications (Primary Option).
• Pros: Works on any device with a SIM card; no app installation required.
• Cons: Higher cost; dependency on mobile network signal.

2. Device Signing (Mobile)

Solaris creates a cryptographic challenge that must be signed by a private key stored in the secure hardware of the customer's smartphone.

• Target Platform: Mobile Apps (Mandatory).
• Pros: Highest security; lower cost (no SMS fees); better UX (Biometrics); works offline (signing happens locally).
• Cons: Requires the customer to have bound their device.

Use cases and key requirements

Different actions require different levels of security. You must use the correct Key Type (Restricted vs. Unrestricted) based on the risk level of the action.

Customers authorize actions using one of two key types:

• Unrestricted keys: Do not require specific user authentication to sign a request. These are typically used for background processes or low-risk actions.
• Restricted keys: Require user authentication via biometrics (e.g., Touch ID, Face ID) to access the private key.
  • iOS: Combine privateKeyUsageflag with userPresence or touchIDAny.
  • Android: Use setUserAuthenticationParameters().

Requirement matrix

The table below lists all use cases requiring SCA and the supported methods.

*If the Clearing Profile has customer_authentication: true

Implement SMS OTP

Prerequisites

• The customer must have a verified mobile number.
• See: Verify mobile number.

Login via SMS OTP

Step 1: Create SMS challenge Call the endpoint to send an SMS to the customer's verified number.

POST /v1/mfa/challenges/sms

Payload:

{
  "person_id": "ec3d16cbc106f481b72d881d90c89cc5cper"
}

Step 2: Verify OTP The customer enters the 6-digit code in your UI. Send it to Solaris to verify.

PUT /v1/mfa/challenges/sms/{sms_id}

• API Reference: SMS Challenges

Implement Device Signing

Device signing uses the cryptographic keys generated during Device Binding.

Login via device signing

Security Requirement: Unrestricted Key.

Step 1: Create challenge Request a challenge for a specific bound device (device_id).

POST /v1/mfa/challenges/devices

Payload:

{
  "device_id": "6642d15e-8f6b-4d28-9186-cdd61d80032a"
}

Response: Returns a string_to_sign and a challenge id.

Step 2: Sign and verify Your app must:

1. Calculate SHA256 hash of the string_to_sign.
2. Sign the hash using the Unrestricted private key on the device.
3. Submit the signature to the verification endpoint.

PUT /v1/mfa/challenges/devices/6642d15e-8f6b-4d28-9186-cdd61d80032a

• API Reference: Device Signing

The Change Request process

Solaris uses a standard Change Request flow for sensitive actions (e.g., updating personal data, making a payment). This ensures that a resource is not modified until the customer explicitly authorizes it via SCA.

Generic Authorization Flow

Data Change via Device Signing

If you are using Device Signing for sensitive data changes, you must use the Restricted Key and enforce Biometric Approval.

Step 1: Initial request

When you call a sensitive endpoint (e.g., PATCH /v1/persons/{id}), Solaris does not update the resource immediately. Instead, it returns a 202 Accepted response containing a Change Request ID.

Example Response:

{
  "id": "b520ce9090c44a989149fe7f2f94a785",
  "status": "AUTHORIZATION_REQUIRED",
  "url": ":env/v1/change_requests/b520ce9090c44a989149fe7f2f94a785/authorize"
}

Step 2: Authorize (Trigger SCA)

Call the authorize endpoint to select the 2FA method.

POST /v1/change_requests/b520ce9090c44a989149fe7f2f94a785/authorize

Payload for SMS:

{
  "person_id": "ec3d16cbc106f481b72d881d90c89cc5cper",
  "delivery_method": "mobile_number"
}

Payload for Device Signing:

{
  "person_id": "ec3d16cbc106f481b72d881d90c89cc5cper",
  "delivery_method": "device_signing",
  "device_id": "6642d15e-8f6b-4d28-9186-cdd61d80032a"
}

Step 3: Confirm

Submit the customer's input to finalize the change.

POST /v1/change_requests/b520ce9090c44a989149fe7f2f94a785/confirm

Payload for SMS:

{
  "person_id": "ec3d16cbc106f481b72d881d90c89cc5cper",
  "tan": "123456"
}

Payload for Device Signing:

{
  "device_id": "6642d15e-8f6b-4d28-9186-cdd61d80032a",
  "signature": "3045022100bdbebd8ba5e4ea23a4ab3d852cbf0968cbc7319c7c4388e0c54bf34e896d19d802205880fca38bf5450bff73d41c675e1444b8e3c75dc8bf764d5c0e9282bd150ade"
}

Once confirmed successfully, the resource (e.g., the address change or the payment) is executed immediately.

What's next?

Now that you have implemented Strong Customer Authentication, you are ready to use the core banking features that require it.

Start building:

• Accounts & Balances: Open accounts and retrieve transaction history.
• SEPA Transfers: Execute payments (requires SCA).
• Cards: Issue and manage cards.