Skip to content This library is free, offered as dana. If it helps your work, donate here →

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Digital payments regulatory impact screener

Screens a payments product or target market against the full stack of applicable regulatory regimes — PSD2/Open Banking, SCA, CFPB rules, interchange caps, AML/KYC, PCI-DSS, and stablecoin/e-money licensing — then flags…

download .md

Purpose

Produce a structured regulatory impact screen for a specific payments product and market — identifying which regimes apply, where the current setup has compliance gaps, which obligations trigger licensing, and what the realistic timeline implications are before launch. Replaces ad hoc "which rules apply to us?" analysis with a repeatable, defensible screening pass.

When to Use

Invoke this skill when the user asks to:

  • Launch a new payments product, wallet, or payment flow and needs to know what regulations apply
  • Enter a new geographic market or jurisdiction with an existing payments product
  • Add a feature that touches money movement (account-to-account, card-on-file, stablecoin settlement, BNPL, payouts)
  • Scope regulatory and licensing obligations before committing engineering or capital
  • Assess whether a current product setup has compliance gaps against a named regime (PSD2, CFPB, AML/KYC)
  • Build a pre-launch regulatory risk register for legal, compliance, or board review

Inputs Required

Before starting, collect:

  • Product description: What the payment product does and how money moves through it (2–4 sentences)
  • Target market(s): Jurisdiction(s) — EU/EEA, UK, US (specify states if relevant), or other named regions
  • Payment instruments involved: Cards, account-to-account/bank transfer, e-money/stored value, stablecoin/crypto, wallet
  • Customer types: Consumers, businesses, or both; and whether funds are held on behalf of users
  • Role in the flow: Merchant, acquirer, PSP/payment facilitator, e-money issuer, account information / payment initiation service, or marketplace
  • Current licenses/registrations held: Any existing authorizations, partner-of-record arrangements, or "none"
  • Target launch date or constraint: Hard deadline or planning horizon, if known

If role-in-the-flow or licenses held are missing, infer the most likely role from the product description, state the assumption explicitly, and screen against that role.

Instructions

Step 1: Classify the Product and Map Money Flow

Establish the regulatory footprint before screening any regime.

  • Identify the regulated activity: holding funds, issuing e-money, initiating payments, accessing accounts, settling in stablecoin, extending credit
  • Determine whether the entity holds customer funds at any point — this is the single biggest driver of licensing obligations
  • Map the flow path: payer → intermediaries → payee, marking every point where funds rest, settle, or change form
  • Tag each jurisdiction the flow touches, including pass-through and settlement locations
  • Output a one-paragraph activity classification used as the basis for all subsequent screening

Step 2: Screen Each Applicable Regime

For each regime below, return: Applies? (Yes / No / Partial) · Why · Specific obligation triggered · Current status (Compliant / Gap / Unknown).

PSD2 / Open Banking (EU/EEA + UK PSRs)

  • Triggers if initiating payments, providing account information, or operating as a PSP in scope
  • Obligations: PISP/AISP authorization or agent status, API access, consent management, third-party provider registration

Strong Customer Authentication (SCA / RTS)

  • Triggers on most EEA/UK electronic payments unless an exemption applies (low-value, TRA, recurring, MIT)
  • Obligations: two-factor authentication, dynamic linking, documented exemption logic

CFPB & US Federal Consumer Rules

  • Screen Reg E (EFTA — electronic transfers, error resolution, disclosures), Reg Z (TILA — if credit/BNPL involved), and CFPB 1033 (data access/open banking) where relevant
  • Obligations: disclosures, dispute/error-resolution timelines, consumer data access rights

Interchange Caps & Routing Rules

  • EU/UK Interchange Fee Regulation caps (0.2% debit / 0.3% credit consumer cards)
  • US Durbin Amendment debit caps and Reg II routing requirements (if a debit card issuer/program)
  • Obligations: fee compliance, network routing choice, surcharging rules by jurisdiction

AML / KYC / CTF

  • Triggers if money transmission, e-money issuance, or fund-holding occurs (BSA/FinCEN MSB registration in US; AMLD/MLR in EU/UK)
  • Obligations: customer due diligence, sanctions screening, transaction monitoring, SAR/STR filing, beneficial ownership

PCI-DSS

  • Triggers whenever card data is stored, processed, or transmitted
  • Obligations: PCI level determination (1–4), SAQ type or ROC, scope-reduction strategy (tokenization, redirect/iframe)

Stablecoin / E-Money / Money Transmission Licensing

  • EU: EMI authorization or MiCA (for stablecoin / e-money tokens)
  • UK: EMI authorization under EMRs
  • US: state money transmitter licenses (MTLs) and FinCEN MSB; emerging federal stablecoin frameworks
  • Obligations: licensing per jurisdiction, safeguarding/segregation of funds, capital and reserve requirements

Step 3: Flag Compliance Gaps

For every regime marked Gap or Unknown:

  • State the gap plainly (what obligation is unmet or unverified)
  • Assign severity: Blocker (cannot launch lawfully) / High (launch risk, remediate before go-live) / Medium (remediate post-launch with a plan) / Watch (monitor for change)
  • Note the remediation owner function (Legal, Compliance, Engineering, Partnerships)
  • Identify whether the gap is closeable via a partner/BIN sponsor/agent arrangement rather than direct licensing

Step 4: Assess Timeline Implications

Translate obligations into a launch timeline view.

  • Flag any licensing or authorization that gates launch and its typical lead time (e.g., EMI/MTL authorizations measured in months, not weeks)
  • Identify obligations achievable in parallel with the build vs. those that are sequential prerequisites
  • Note jurisdiction sequencing — markets that can launch first vs. those that require longer authorization
  • Compare against the stated launch date and call out any conflicts explicitly

Step 5: Produce the Risk Register and Recommended Path

  • Consolidate findings into a single risk register table
  • Recommend a launch path: direct authorization vs. partner-of-record vs. phased market entry, with the rationale
  • Surface the top 3 actions to take first, ordered by what unblocks the timeline

Output Format

  • Structure: Activity classification paragraph → regime-by-regime screen table → gap flags → timeline view → consolidated risk register → recommended path
  • Length: 1,000–1,400 words
  • Format: Structured document with one summary table (regime screen) and one risk register table; supporting analysis in concise bullets
  • Sections: Product & Money-Flow Classification · Regime Screen (7 regimes) · Compliance Gaps · Timeline Implications · Risk Register · Recommended Path & Top 3 Actions
  • Tone: Regulatory counsel — precise, conservative on ambiguity, explicit about assumptions; flags uncertainty as "Unknown — verify" rather than guessing compliance

Quality Checklist

Before delivering output, verify:

  • [ ] All 7 regimes are screened with an explicit Yes / No / Partial applicability call — none skipped
  • [ ] Whether the entity holds customer funds is stated explicitly and drives the licensing analysis
  • [ ] Every Gap or Unknown carries a severity label (Blocker / High / Medium / Watch) and an owner function
  • [ ] At least one licensing item is assessed for lead time against the stated launch date
  • [ ] The risk register includes every regime marked Gap or Unknown — counts reconcile with the screen
  • [ ] Any assumptions about role-in-the-flow or jurisdiction are stated, not buried

Notes

  • Fund-holding is the pivot point: products that never touch customer funds (pure facilitation, redirect-to-bank, full tokenization) often sidestep the heaviest licensing obligations — flag this path when the product allows it
  • Partner-of-record / agent / BIN-sponsor arrangements frequently convert a Blocker into a Medium by borrowing a licensed entity's authorization — always evaluate this before recommending direct licensing
  • This screen is a structured first-pass triage to scope obligations and sequence work; it is not a legal opinion and should be confirmed with jurisdiction-specific counsel before launch
  • When the product spans multiple US states, treat money transmitter licensing as a state-by-state matrix, not a single national obligation

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills