How We Research Payments Data
How Business Expert sources, verifies, and updates the data on the UK Payments Hub.
What backs the data on this hub
3 observationsPrimary sources only for product, pricing, and statistical claims
Pay.UK, UK Finance, Bank of England, FCA, ONS, HMRC, individual banks
Editorial governance — 10-evidence-governance.md
Every figure carries an observation_id, source_id, period, last-checked date, and method status
6 data attributes per surface, validated by the pre-publish gate
Engineering governance — 09-presentation-design-system.md §3.3, §5
Observed, derived, estimated and survey figures are visually distinct
EstimateBadge surfaces inline next to every non-observed value
Editorial governance — 09-presentation-design-system.md §10
Sources we use, and why
Every load-bearing figure on this hub comes from a named primary source. For UK payments, that means Pay.UK quarterly statistics, UK Finance UK Payment Markets reports, Bank of England statistical releases, the Financial Conduct Authority's published data, the Office for National Statistics, HMRC, and individual provider regulatory disclosures.
We do not treat price-comparison sites, affiliate aggregators, or other commercial review platforms as sources for product or statistical claims. Where a secondary source is the only way to reach a number, the page is built without that number rather than with a weakly-supported one.
How we collect data
Quarterly and annual statistical releases are pulled directly from the publishing body's website on the day of publication where possible. Each retrieval records the exact source URL, the publication date stated by the publisher, and the date our editor verified the figure against that publication.
Where a publisher provides only a PDF, we transcribe the underlying tables into the citation engine and store both the PDF URL and the transcribed values. Numbers are never re-derived from screenshots, third-party summaries, or AI-generated extractions.
How we normalise across sources
Different publishers report on different period boundaries: calendar year, fiscal year, rolling four quarters. Where a metric appears on more than one of our pages, it is normalised to a single period boundary in the citation engine and the original boundary is noted in the source strip.
We never compare figures across sources without first checking the underlying methodology notes. If two sources count different things — for example, one counts mandates and another counts payments — the difference is surfaced in the chart footnote, not hidden inside an apparent disagreement.
How we calculate derived figures
A small number of figures on the hub are derived rather than directly observed: typically year-on-year growth rates, share calculations across rails, or per-capita normalisations. Each derived figure carries the calculation in plain English in its source strip — for example, 'derived: contactless transaction volume / total card transaction volume, 2024'.
Derived figures are flagged with a Derived EstimateBadge so a reader scanning the page knows which numbers are direct readings and which are calculations. Survey-based figures get a Survey badge for the same reason.
Known limitations
Volume and value figures across rails are not directly comparable on a per-transaction basis: cards count individual purchases, Bacs counts batched mandates, and CHAPS counts wholesale settlements. Where this matters for the read of a claim, the relevant chart footnote is shown alongside the visual.
Mobile-wallet share is published once a year by UK Finance and is therefore the most lagging indicator on the hub. APP fraud reimbursement data lags the most recent quarter by roughly six months. We surface the publication lag rather than smoothing over it with intermediate estimates.
Our update schedule
Pay.UK and UK Finance reports refresh quarterly. Bank of England statistical series refresh monthly. ONS Retail Sales Index refreshes monthly. LINK and PSR ATM data refresh annually. Provider regulatory disclosures refresh on each provider's reporting cadence, typically annually.
The freshness state of every page is computed from the lag between today and the most recent verified-at date across that page's bound observations. Pages whose data has fallen out of freshness display a visible warning above the data; we do not show stale data as fresh.
Revision history
When a publisher releases a revised figure, the previous value is marked superseded in the citation engine and the page is rebuilt. The dateModified field in the structured data reflects the most recent verification across the whole page.
The log below records every review-state transition for hub observations — approvals, publications, supersessions, and corrections — in chronological order.
Revision log
No revision events have been logged for this page.
Editorial review
Every page on the hub is reviewed by a named editor against an 8-stage editorial workflow before publication: brief, source map, outline, draft, trust pass, adversarial review against 28 named failure modes, human-input placeholders, and a 16-check pre-publish gate. The pre-publish gate is enforced in code, not by docstring.
Pages that fail the gate are held in DRAFT until they pass. We do not publish on a deadline at the cost of trust signals.
How to cite this page
Updated
Business Expert. (2026). "How We Research Payments Data." UK Payments Data Hub. Available at: https://businessexpert.co.uk/data/payments/methodology/ (updated 2026-04-29).
Publisher: Business Expert