# Payments Law EU

> A structured archive of EU payments, financial-services, and digital-identity legislation designed for agent traversal.

## Scope

The centre of gravity is payments: PSD2; the PSD3 and PSR texts, with current legal status and historical source editions explicitly identified; and the open-banking and financial-data-access proposals alongside them. Around that core sits the framework legislation a payments analyst routinely needs to consult: electronic money, interchange and cross-border payments, anti-money-laundering and funds transfer, consumer credit and distance marketing, capital requirements and prudential supervision, settlement finality, electronic identification, and the crypto-asset, data-protection, digital-operational-resilience, and AI Act regimes that intersect with payments.

Scope is principled rather than exhaustive. Beyond the core set, an instrument is included only where it is cross-referenced from the core set more than once. That keeps the corpus bounded and helps ensure that acts an agent is likely to chase from a payments question are already resolvable on-site.

## Structure

Each instrument is parsed from its EUR-Lex source, split into chapter-level markdown chunks with consistent YAML frontmatter, and paired with a machine-readable `instrument.yaml` at its root. Cross-references between articles and across instruments are resolved and exposed in the YAML index so agents can traverse the corpus without re-parsing the text.

## Discovery

Three structured surfaces, ordered by retrieval cost. Use them instead of fetching the HTML pages, which order the Explanatory Memorandum before the operative articles and typically truncate before reaching the binding text.

The `{id}` segment is the lowercased instrument identifier used in `instruments.yaml` (for example `psd-2`, `psr`, `eidas-2`).

**To answer a question about a specific instrument**, fetch:

1. `https://paymentslaw.eu/{id}/instrument.yaml` — article-level YAML index covering every article: title, chapter path, chunk file, applicable entities, topics, keywords, obligation counts, resolved internal and external references. Use this to identify the article(s) in scope.
2. The `chunk_file` URLs referenced in step 1 — chapter-level markdown with full article text and YAML frontmatter at `https://paymentslaw.eu/{id}/chunks/{chunk_id}.md`. Fetch only the chunks that cover the article(s) in scope.

**For an instrument-wide overview** (no article narrowing needed), fetch:

- `https://paymentslaw.eu/{id}.md` — flat operative-text markdown. Memorandum and recitals suppressed; chapters and articles inline. Use for fast triage when the question doesn't yet have an article focus.

**For cross-instrument questions**, fetch first:

- `https://paymentslaw.eu/instruments.yaml` — site-level index of every instrument: identity (CELEX, ELI), instrument type, status, key dates, relationship graph (`amends`, `repeals`, `supplements`, plus `amends_external` and `amended_by_external`/`repealed_by_external` for amendment and repeal edges whose other end is outside the corpus — identified by CELEX and ELI rather than instrument id, each carrying `via_article` — and `via_articles` naming the operative amending or repealing article of each curated in-corpus edge), and a direct URL into each instrument's YAML. Use the relationship graph to scope the question to the relevant instruments before fetching their per-instrument indexes.

**Commission proposals** — instruments whose `instruments.yaml` status is `proposal` — additionally expose `https://paymentslaw.eu/{id}/chunks/preamble.md`, which contains the Commission's Explanatory Memorandum. Treat that file as `explanatory_material` per the source hierarchy below — not as authority for legal requirements. Key this rule on the site-level `instruments.yaml` status. Council compromise texts and published final acts do not expose a Commission memorandum as part of their current text. A memorandum belongs to its Commission proposal edition, preserved in the historical HTML under `/{id}/versions/`. Read `legal_status` and source provenance to identify the current edition; a coarse compatibility field is not sufficient.

**For "what changed between the 2023 proposals and the Council compromise texts"** (PSR and PSD3 only), fetch:

- `https://paymentslaw.eu/changes/index.yaml` — package-level change index: counts per instrument and links to each compact index.
- `https://paymentslaw.eu/{id}/changes.yaml` — per-instrument compact index: one entry per aligned article with textual state (`unchanged`, `amended_limited`, `amended_substantial`, `inserted`, `deleted`), similarity, a mechanical summary, `editorial_review_state` and any curated materiality marker.
- `https://paymentslaw.eu/{id}/changes/art-{n}.md` — one article's word-level diff as markdown (`{+inserted+}`, `[-deleted-]`); `.json` for the same artefact structured.

Textual classification is mechanical and follows the published method (`https://paymentslaw.eu/method/`). Materiality markers are curated and selective, not a complete assessment: `editorial_review_state: not_assessed` is the default serialisation and never means "not material".

**For "where did this obligation go" across PSD2, the delegated acts and the package**, fetch a topic map. A topic map is a hand-curated correlation table for one subject, tracing each obligation from its baseline instrument to the specified package edition, with a status for the character of the move (`same`, `edited`, `repositioned`, `promoted`, `new`, `reopened`, `removed`, `gap`) and a per-row verification level. It reaches material the mechanical article-to-article correspondence cannot see — delegated acts and supervisory guidance — and is selective rather than complete.

- `https://paymentslaw.eu/psd3-psr-transition/sca-relocation-map.yaml` — strong customer authentication: 39 obligations across PSD2, Delegated Regulation 2018/389 and the PSR. `.json` and `.csv` serve the same rows. Human page at `https://paymentslaw.eu/psd3-psr-transition/sca/`.

Rows whose `verification` is not `verified_primary` carry a "today" position that was not read from operative text held in this corpus; the row's `sources` say why. The SCA map analyses the April 2026 Council texts. It is not a mapping of the published final acts and does not replace any correlation tables in those acts. Follow each row’s cited source edition.

## MCP server

The same corpus is queryable as a read-only MCP server over Streamable HTTP at `https://mcp.paymentslaw.eu/mcp/v1`. Setup instructions for the common clients are at `https://paymentslaw.eu/connect/`.

The server's tools: `search_legislation`, `get_provision`, `get_instrument`, `list_instruments`, `list_provisions`, `resolve_citation`, `compare_versions`, `list_version_changes`, `search_defined_terms`, `get_defined_term`, `search`, `fetch`, `get_orientation`, `get_source_notes`.
`get_source_notes` retrieves complete held source-note bodies, including preamble and annex notes, with pagination and exact keys that distinguish reused printed markers. It does not infer provision ownership; unavailable historical versions return a stable source-edition link.
`search` and `fetch` are the OpenAI-compatible pair for clients that expect those names; a fetch id is the cite anchor a search result carries. The other tools return more — warnings, provenance, paging — and are preferred where the client can call them. `get_orientation` returns curated reading pathways into the corpus for a stated audience; its prose is editorial and labelled as such.

Every provision-bearing response carries a `cite` anchor naming exactly what was served — echo it rather than composing a citation of your own. A search snippet is served text but is not the provision: open a hit with `get_provision` before citing it. Responses also carry the instrument's text state and, where an as-adopted text is amended by another instrument in this corpus, a warning saying so.

The file surfaces described above remain fully supported and are the right route for agents without an MCP client.

## Source hierarchy

When answering legal questions, use sources in this priority order:

1. **Operative articles** — binding law.
2. **Annexes and schedules** — binding, subordinate to the articles they attach to.
3. **Recitals** — interpretive, non-binding, may aid construction.
4. **Explanatory memoranda, Commission proposals, and policy summaries** — non-binding, background only; not authority for legal requirements.

If sources conflict, prioritise higher-ranked sources over lower-ranked ones.

## Notes for agents

- `instruments.yaml` is the single source of truth for which instruments exist and how they relate. This file (`llms.txt`) is stable orientation, not a corpus catalogue.
- Status values in `instruments.yaml` distinguish `proposal`, `council_compromise_text`, `oj_published`, `in_force_not_applicable`, `applicable`, `in_force`, `partially_repealed`, `repealed`, and `superseded`. Combine these with `dates.in_force_from` and `dates.in_force_until` to answer "what is in force on date X?" correctly, particularly for instruments amended before being repealed.
- Per-instrument `instrument.yaml` files retain a coarse `status` field for compatibility; for example, a Council compromise edition can retain `status: proposal`. Both index surfaces carry `legal_status`, which identifies the precise current stage and is the field to prefer; `instruments.yaml` additionally carries `lifecycle_stage` (`pre_adoption`, `published_oj`, `in_force_not_yet_applicable`, `applicable`, or `null` outside that pipeline).
- PSD3: current edition st-8222-2026; legal_status council_compromise_text; Council document 8222/26. Council compromise text, not yet law.
- PSR: current edition st-8221-2026; legal_status council_compromise_text; Council document 8221/26. Council compromise text, not yet law.
- Historical proposal-to-compromise comparisons identify both source versions explicitly. They do not compare a proposal with the published act. Historical editions remain addressable at `/{id}/versions/{versionId}/`.
- On Council editions, the top-level CELEX identifies the proposal; on published editions it identifies the final act. Read `legal_status`, current version provenance and applicability together; publication does not mean all provisions apply immediately.
- `llms-full.txt` is not published. The corpus is too large for a useful inline listing; the supported access pattern is the three-layer discovery flow above.

## Credits

Built and maintained by Matt Berryman, drawing on fifteen years in payments, fraud risk, regulatory compliance and 3-D Secure authentication. Portfolio: [mattberryman.com](https://mattberryman.com). LinkedIn: [linkedin.com/in/mattberryman](https://www.linkedin.com/in/mattberryman/).