# 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 today; the PSD3 and PSR Council compromise texts as they move towards adoption (current agreed texts, not yet law, with their 2023 Commission proposals preserved as pinned versions); 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` for amendment targets outside the corpus, identified by CELEX and ELI rather than instrument id), 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: the council-compromise-text instruments (`psr`, `psd-3`) do not expose a preamble — their memoranda belong to the superseded 2023 proposals pinned under `/{id}/versions/` — even though their per-instrument `instrument.yaml` still reports the coarse status `proposal` (legacy divergence, noted below).

**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".

## 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`, `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.
- Legacy divergence, kept for compatibility: per-instrument `instrument.yaml` files emit the coarse `status` vocabulary only (`proposal` for the PSR/PSD3 council-text instruments), while the site-level `instruments.yaml` emits the richer value (`council_compromise_text`). Both surfaces carry `legal_status`, which always agrees 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).
- For PSR and PSD3 the text served at the unversioned URLs is the April 2026 Council final compromise text — agreed, awaiting formal adoption and Official Journal publication, not yet law; article numbers and dates may change on publication in the Official Journal. The superseded 2023 Commission proposals remain addressable at `/{id}/versions/{versionId}/`. The top-level `celex` on these instruments is the Commission proposal's CELEX (Council ST documents carry none); the current version records identify themselves by Council document number and interinstitutional file instead.
- `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/).