Understand SCA basics

Introduction

Strong Customer Authentication (SCA), is a regulatory requirement under the second European Payment Services Directive (PSD2). It strengthens online payment security and protects users from fraud.

Applicability:

Since March 14, 2022, SCA applies to all online transactions in the European Economic Area (EEA) and the United Kingdom.

Purpose:

SCA was introduced to ensure secure payments, reduce fraud, and comply with DSP2 regulatory requirements (ACPR & RTS). It builds on the original PSD (2007) by reinforcing identity verification and secure operations for payment services.

flowchart TD
    %% --- Nodes ---
    A([User initiates SCA Setup]):::draft
    B[Email verification]:::pending
    C[Phone number verification]:::pending
    D[Secret code setup]:::pending
    E[Secret code verification]:::pending
    F([✅ User's SCA Validated]):::active

    %% --- Links ---
    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

    %% --- External Actors (Dashed borders for User actions) ---
    style A stroke-dasharray: 5 5
    style B stroke-dasharray: 5 5
    style C stroke-dasharray: 5 5
    style D stroke-dasharray: 5 5
    style E stroke-dasharray: 5 5

    %% --- Styles ---
    classDef draft fill:#fff0f6,stroke:#c41d7f,stroke-width:2px
    classDef pending fill:#e6f7ff,stroke:#1890ff,stroke-width:2px
    classDef active fill:#f6ffed,stroke:#52c41a,stroke-width:2px

📘

Check the graph's legend here.

---

Why SCA is Required

Strong Customer Authentication (SCA) is a legal obligation under PSD2. Its purpose is threefold:

1. Regulatory compliance - Ensures alignment with DSP2, ACPR supervision, and Regulatory Technical Standards (RTS).
2. Security - Protects users against fraud by reinforcing identity checks.
3. User trust - Provides a safer experience while maintaining usability.

---

When SCA is Required

SCA is not applied uniformly. It is required in specific contexts:

1. First Login and Periodic Re-authentication

• At the first login (after KYC onboarding confirmed by MPS), users must authenticate with two independent factors mecanism.
• Afterwards, re-authentication is required every 180 days.

During the 180-day period, users may still access:

• Their account balance
• Their whole transaction history

using only their regular password. This exception is designed to preserve usability while remaining compliant.

---

2. Sensitive Remote Operations

SCA is systematically required when performing operations that could cause financial loss or involve sensitive data changes.

Examples:

• Adding a new beneficiary
• Updating personal information

Each such action must be explicitly authorized by the user through the full SCA process.

---

3. Payment Operations

SCA is mandatory for every payment operation triggered by a user.

Example:

• Executing an external SEPA transfer (from the user’s payment account to another external bank account).

In practice at MPS, this means no transfer or outgoing payment can be initiated without a completed SCA workflow.

---

flowchart TD
    subgraph LOG ["<b><font size='3'>User Account Connection</font></b>"]
        A([Login + password input]):::draft
        B[Setup SCA Required]:::update
        C{Verify Date of<br/>Last 2FA}:::pending
        E[Perform 2FA]:::pending
    end

    subgraph USE ["<b><font size='3'>User Connected</font></b>"]
        F[Access non-sensitive data]:::active
        G{Trigger new operation}:::draft
        H[Perform 2FA]:::pending
        I([Authorized: Sensitive Data<br/>or Pay-out execution]):::active
    end

    %% --- Links ---
    A -->|First time| B
    A -->|SCA already setup| C
    C -->|< 180 days| F
    C -->|> 180 days| E
    B --> E
    E --> F
    F --> G
    G -->|Non-sensitive| F
    G -->|Sensitive| H
    H --> I

    %% --- External Actors (User Actions) ---
    style A stroke-dasharray: 5 5
    style E stroke-dasharray: 5 5
    style G stroke-dasharray: 5 5
    style H stroke-dasharray: 5 5

    %% --- Styles ---
    classDef draft fill:#fff0f6,stroke:#c41d7f,stroke-width:2px
    classDef pending fill:#e6f7ff,stroke:#1890ff,stroke-width:2px
    classDef active fill:#f6ffed,stroke:#52c41a,stroke-width:2px
    classDef update fill:#fffbe6,stroke:#faad14,stroke-width:2px

📘

Check the graph's legend here.

---

SCA Factors

SCA is based on the principle of combining two out of three independent factor categories. If one factor is compromised, it must not affect the reliability of the others.

Factors Used at MPS

At MPS, three factors are implemented in practice:

• Email — used as a possession check.
• Phone number — used as a possession check through SMS validation.
• Secret code — used as a knowledge factor, set up and confirmed by the user.

A user is considered fully authenticated (workflow_completed = true) only once all three factors are validated. This ensures compliance with PSD2 and the highest level of security.

---

Key Concepts

Platform (platformUUID)

A Universally Unique IDentifier for each platform.

User (userUUID)

A Universally Unique IDentifier for each user across API requests (project owners, investors, managers).

Strong Customer Authentication (SCA)

Sequential multi-factor authentication mechanism: email → phone → secret code.

Workflow

A sequential set of validations, accessible via GET strong_auth/status.

JWT (JSON Web Token)

A Short-lived token proving SCA is done. Must be reused while valid.

Session vs Operation

• Per session → access valid for a given time.
• Per operation → SCA required for each sensitive operation.

---

Typical Workflow (SCA setting)

After creating a user, the Strong Authentication workflow runs as follows:

1. Email verification

• POST OTP generate /email_by_email → POST OTP verify /email_by_email
• For a new user, only by_email OTP is required.
• If the email source is reset later but phone number is already validated, validation will require both by_email and by_sms.

2. Phone number verification

• Always requires the two verifications:

  a. Verification by email

  b. Verification by SMS

• Each step uses: POST OTP generate → POST OTP verify

3. Secret code setup

• User sets a code with POST Secret Code Setup.

• Verification then requires the two methods:

  a. Verification by email

  b. Verification by SMS

• Once fully validated → Retrieve the JWT token with POST Secret Code Verify.

---

Resetting a Source

Use the endpoint : POST strong_auth/reset/{source}

Then you must redo the verification for the specific source (email, phone_number, or secret_code).

✅

Other validated factors remain intact.

Example: Resetting phone_number → Only the phone number verification from the workflow above needs to be done.

Don't forget that you will need the by_email and by_sms OTPs if you reset the email source but that you keep your phone_number validated.

---

Key Takeaways

• SCA is a regulatory requirement under PSD2, supervised by ACPR and RTS.
• It protects sensitive operations and all payments through multi-factor checks.
• At MPS, the workflow relies on email, phone, and secret code, all required for full validation.
• Use the GET Strong Auth Status endpoint to confirm readiness before initiating any regulated action.

---

Want more ? Check our Swagger for technical information :