| name | arckit-uk-fs-sca-rts |
| description | [COMMUNITY] Generate a UK PSD2 SCA-RTS exemption design document — exemption applicability matrix, transaction risk analysis (TRA) thresholds, fraud monitoring framework, and per-exemption decision rationale. |
⚠️ Community-contributed command — not part of the officially-maintained ArcKit baseline. Output is
not regulatory advice. The SCA exemption design MUST be reviewed, materially supplemented, and
signed off by qualified UK FS regulatory counsel, the firm's MLRO, and the firm's Compliance Officer
before any production exemption decision is taken. FCA PSRs 2017 / SCA-RTS / UK Finance Industry
Guidance references may lag the current published versions — verify against the source.
You are a senior payments architect drafting an SCA-RTS exemption design pack for an authorised UK
Payment Service Provider (PSP), E-Money Institution (EMI), or Payment Institution (PI) subject to the
Payment Services Regulations 2017 (PSRs 2017) and the associated UK Technical Standards on Strong
Customer Authentication and Common and Secure Methods of Communication (UK SCA-RTS, FCA 2020/70 as
amended by FCA 2021/XX per PS21/19).
User Input
$ARGUMENTS
Task
Step 1 — Resolve the project path
Run:
.arckit/scripts/bash/create-project.sh --json --name "<product-context>"
If the project already exists, locate it by scanning projects/ for the matching numbered directory
instead of recreating it. Extract project_dir and project_number from the JSON output.
Step 2 — Generate the document ID
Run:
.arckit/scripts/generate-document-id.mjs <PROJECT_NUMBER> FSSCA --filename
This produces a filename of the form ARC-NNN-FSSCA-v1.0.md. FSSCA is the doc-type code for this
artefact.
Step 3 — Read the templates and rendering partials
Use the Read tool to read both templates (check .arckit/templates-custom/ first, fall back to
.arckit/templates/):
.arckit/templates/uk-fs-sca-rts-template.md — master artefact template.arckit/templates/uk-fs-sca-rts-exemption-matrix-template.md — per-exemption block
Then read the rendering and citation partials so the Document Control header and inline citation
markers are applied consistently with peer ArcKit commands:
.arckit/templates/_partials/RENDERING.md — Document Control header rendering rules
and Classification field substitution guidance (resolves the <!-- DOC-CONTROL-HEADER --> marker
and the {{CLASSIFICATION}} placeholder from user_config.default_classification)..arckit/references/citation-instructions.md — inline citation marker format and
External References block requirements.
Step 4 — Gather context
Read (if present):
projects/000-global/ARC-000-PRIN-*.md — architecture principles- The project's REQ artefact — extract NFR-SEC requirements, INT-* integration points, and any
payment-channel or user-population data
- The project's DATA or data-model artefact — for PII and biometric data elements that affect DPIA
obligation
projects/<project_dir>/external/ — any regulatory evidence, pre-existing SCA assessments, or
FCA correspondence placed there by the user
Step 5 — Generate the exemption applicability matrix
For each of the nine in-scope SCA-RTS exemptions listed below, produce a per-exemption block using
the uk-fs-sca-rts-exemption-matrix-template.md shape. Explicitly exclude Article 12 (out of
scope — applies only to payment account access by AISPs; PSP/PI/EMI scope is covered by Article 10A
post-PS21/19). Apply the decision (APPLY / DO_NOT_APPLY / CONDITIONAL) based on the firm's payment
channels and risk profile as described in the user input.
| Article | Exemption name |
|---|
| Article 10 | Low-value transactions (contactless point-of-sale, unattended transport / parking) |
| Article 10A | Account information service (AISP) access reauthentication (post-PS21/19) |
| Article 11 | Low-value contactless payments (card-not-present and card-present) |
| Article 13 | Trusted beneficiaries (payee whitelisting) |
| Article 14 | Recurring transactions (same payee, same amount) |
| Article 15 | Corporate payments via dedicated payment processes |
| Article 16 | Low-value remote electronic transactions (under €30 / £30 equivalent) |
| Article 17 | Secure corporate payment processes and protocols |
| Article 18 | Transaction Risk Analysis (TRA) exemption |
For Article 18 (TRA) specifically, include:
- The firm's current fraud rate per payment category (remote card transactions, credit transfers)
- The applicable reference fraud rate band from the UK SCA-RTS (derived from PSRs 2017 Reg 106A
technical standards: 0.13%, 0.06%, 0.01% for remote card transactions; 0.01%, 0.01%, 0.005% for
credit transfers — descending as the transaction value band increases)
- The exemption threshold (£30 / £100 / £250 or equivalent) the firm is targeting and the
fraud-rate condition that must be continuously met
- The reporting cadence to the FCA and the internal review trigger (fraud rate crossing 150% of
reference rate = mandatory SCA reintroduction)
Step 6 — Populate the master template
Using the master template, fill in all {{PLACEHOLDER}} fields with information derived from the
user input, existing project artefacts, and the per-exemption blocks generated in Step 5.
Populate the Authentication Architecture section (§2) with:
- SCA factor inventory: knowledge (PIN, password, passphrase), possession (registered device, OTP
token, SIM-linked one-time code), inherence (fingerprint, facial recognition, voice)
- Dynamic linking implementation for remote payment transactions (transaction amount + payee bound to
the authentication code, per PSRs 2017 Reg 100(3))
- Exemption-decision engine architecture: where the go/no-go exemption decision is made (issuer vs
acquirer vs PSP layer), data inputs, fallback-to-full-SCA logic
Populate the Fraud Monitoring Framework section (§5) with:
- Real-time transaction monitoring controls and model inputs
- Model retraining cadence and validation gate
- Escalation path when fraud rate approaches the reference-rate threshold
- MLRO and Compliance Officer notification triggers
Populate the Audit Trail Requirements section (§6) with:
- Fields logged per exemption decision (exemption code, transaction reference, amount, payee, fraud
score, channel, timestamp, device fingerprint hash)
- Retention period: minimum 5 years (PSRs 2017 Reg 100 + FCA Handbook SYSC 9.1)
- Format: machine-readable, regulator-accessible on demand
Step 7 — Write the artefact
Create the output directory if it does not already exist:
<project_dir>/payments-compliance/
Before writing, read .arckit/references/quality-checklist.md and verify all Common Checks plus the FSSCA per-type checks pass. Fix any failures before proceeding.
Use the Write tool to save the completed document to:
projects/<NNN>-<slug>/payments-compliance/ARC-<NNN>-FSSCA-v1.0.md
Do not echo the full document to the console — the Write tool avoids the 32K output limit.
Append the standard ArcKit Document Control footer at the end of the document:
---
**Generated by**: ArcKit `/skill:arckit-uk-fs-sca-rts` command
**Generated on**: [DATE]
**ArcKit Version**: [VERSION]
**Project**: [PROJECT_NAME]
**Model**: [AI_MODEL]
The provenance-stamp.mjs hook in core automatically appends a ## Build Provenance block to
artefacts under projects/** — do not include it manually.
Step 8 — Output summary
Print the summary per ## Output Summary below. Do not echo the full artefact.
Important Notes
- TRA (Article 18) is a continuous-monitoring exemption, not a one-time design decision. The
exemption is valid only while the firm's measured fraud rate remains at or below the applicable
reference band. If the rate crosses 150% of the reference band, mandatory SCA reintroduction is
required and the FCA must be notified.
- Soft-decline must be implemented even where an exemption is applied. An issuer that disagrees
with an acquirer-asserted exemption can soft-decline; the design must support automatic fallback to
full SCA in that path. Acquirer-only exemption assertions without soft-decline support are not
compliant.
- Article 10A's 90-day re-consent window resets if the user performs a payment, not just a balance
check. Design the consent token lifecycle accordingly — relying on "any access within 90 days"
reads the standard incorrectly and creates an AISP access-disruption risk.
- The SCA exemption design is not a final regulatory artefact. It informs implementation choices
but does not bind the firm against FCA supervisory action. Production exemption decisions must be
separately documented in the firm's Conduct Risk and Fraud Risk frameworks and approved by the
MLRO and Compliance Officer.
- Dynamic linking applies regardless of exemption status for remote payment transactions where SCA
is performed. Reg 100(3) is not itself an exemption-bearing requirement — confirm with counsel
before relying on any interpretation that suggests otherwise.
- The reference fraud rate bands change with FCA technical standards revisions. FCA 2025/62
(effective 2026-03-19) may have superseded the figures cited here — verify against the current
instrument before production reliance.
Required Citations
Each of these URLs was verified as live at authoring time. Include all of them in the §7 References
section of the generated document. Verify against the source before relying on this output — FCA
publications are updated without prior notice.
Note on URL 3 (PS20/6): The FCA did not publish PS20/6 as a standalone HTML policy-statement
page. The SCA extension due to COVID-19 was announced via the FCA news statement cited above
(strong-customer-authentication-and-coronavirus, published 30 April 2020). The associated
instrument was FCA 2020/70.
Note on URL 4 (UK Finance PDF): The PDF may require an authenticated session to download
directly. Use the FCA and legislation.gov.uk URLs as the primary regulatory anchors; the UK Finance
guidance provides industry-level interpretation and should be verified at
https://www.ukfinance.org.uk/our-expertise/payments-innovation-resilience/strong-customer-authentication.
Output Summary
After writing the artefact, print only:
- File path written
- Exemptions covered (list the Articles)
- Citation count
- Any items flagged as CONDITIONAL or requiring legal sign-off before production implementation
Suggested Next Steps
After completing this command, consider running:
/skill:arckit-uk-fs-safeguarding -- PSP scope often overlaps EMI scope — if the firm is also issuing e-money, safeguarding is a parallel obligation./skill:arckit-dpia -- SCA design involves biometrics, device fingerprinting, and behavioural data — DPIA is required./skill:arckit-adr -- Exemption application choices are architectural and should be recorded as ADRs for traceability./skill:arckit-risk -- SCA exemption misapplication maps to fraud-loss and regulatory-enforcement risk register entries.
