The diagram below shows a high-level workflow of how your application user journey at the least must enforce in order to comply with SCA requirements.

Instead of enforcing a UI component which will authenticate Striga (LSPEU) directly with the end user, such that we manage sessions, we have taken a legally heavier approach in not interfering directly with whatever user/password management flows your application may already have setup. This is the approach developed by our legal/compliance team and requires regulatory notification on our end, however preserves UX with the least invasive possible components.

In outsourcing password management and user session management to you, us as the licensed provider in the flow are at risk and depend upon your implementation of these APIs to remain compliant. Namely, please ensure to note the following -

We do not manage user passwords and hence will need to be made aware when a user successfully completes a forgot password workflow on your application or has a failed login attempt. We are legally required to track failed login attempts to enforce a time based lockout and expect your application to hit our /user/record-event to notify us of these events. More information will be shared by compliance about what happens in various scenarios as part of our onboarding process.
Please do not at any point in time store TOTP/Passkey secrets and attempt to circumvent SCA provisions by acting on behalf of the user. This comes with high fines and penalties.
Ensure the implementation of a strong password/OAuth/login mechanism and industry best practices to secure user accounts.
When a user wishes to reset their SMS OTP factor (i.e. change mobile number), their TOTP factor or Passkey, we are required to enforce that it is the user acting on their own behalf, prompting an automated liveness check on such events.
We recommend using the concept of "Trusted Beneficiaries" and "Standing Orders" to enable the smoothest possible UX for automated flows.

Lifetimes and limits

Item	Value
SCA session	180 days
History sub-window	90 days
SMS code	5 minutes
TOTP / passkey challenge	10 minutes
Attempt cap per challenge	5
Resend (SMS)	Twilio-managed; deduped per channel
Resend (passkey / TOTP)	Not supported (`31100` for passkey; TOTP has no server challenge)

Error codes

Code	Meaning
`30031`	Invalid verification code, or Dynamic Linking mismatch (the response `reason` field disambiguates).
`30043`	User is suspended; SCA flows reject.
`30070`	SCA session required or expired. Re-authenticate via `/user/login/start` + `/user/login/complete`.
`30073`	`whitelistedIbanId` or `whitelistedAddressId` not found or not `ACTIVATED`.
`30074`	`verificationMethod` was supplied but the application's `scaEnabled` is not `true`.
`30075`	Address trust is only supported for `USDC`, `USDC_POLYGON`, `USDC_SOL`.
`31097`	Requested factor is not enrolled for this user.
`31099`	Factor is not in the application's `allowedScaMethods`.
`31100`	Resend not supported for passkey.
`64009`	Whitelisted USDC address must be trusted before creating a standing order.
`64010`	Standing-order factor not enrolled.
`64011`	Whitelisted IBAN must be trusted before creating a `CRYPTO_TO_FIAT` standing order.