Skip to content

Payments Intelligence

Methodology

An automated pipeline that monitors developments in payments and fintech. It retrieves material from live sources, filters it, analyses it, and stores the result with full attribution. Every factual claim in a brief traces back to a URL that was actually fetched.

How it works

  1. 01
    Retrieval

    Each watchlist topic is queried against a search API and, in parallel, against RSS feeds from primary sources such as the ECB. Feed items are fetched in full and the article body is extracted from the page.

  2. 02
    Triage

    A lightweight model scores every retrieved source 0–100 on whether it actually addresses the topic. Marketing pages, index pages and off-topic material are dropped before anything expensive runs.

  3. 03
    Filtering and ranking

    Rule-based checks remove duplicates, boilerplate and navigation text. Sources are ranked by editorial tier — regulators first, then company primary sources, then trade press — which deliberately overrides the search engine’s own ordering.

  4. 04
    Analysis

    A stronger model produces the written brief. It may use only the retrieved evidence, must cite every factual claim, and must return “insufficient evidence” rather than fill gaps.

  5. 05
    Structured extraction

    A second model call extracts machine-readable fields: impact score, confidence score, companies, segments, geography and what to monitor next.

  6. 06
    Publication gate and storage

    Four conditions must all hold: not refused, enough evidence, at least three ranked sources, confidence ≥ 40. What passes is deduplicated against prior stories by a deterministic event fingerprint and stored. What fails is logged and never stored.

On the scores

Impact estimates how consequential a development is for the payments value chain, from routine to structural change. Confidence reflects the evidence, not the claim: how many independent sources were available, whether any were primary, and whether full article text could be retrieved. A source available only as a headline caps confidence regardless of how authoritative it is.

Both scores are model-assigned integers 0–100. They are useful for ranking and filtering, not as calibrated measurements. The publication gate floor is 40 — nothing below that is stored — so the bands start there:

0–39Low
40–59Moderate
60–79High
80–100Very high

A confidence of 65 is therefore High, not moderate. Low-confidence items are flagged rather than hidden.

On momentum

Market Pulse compares a window (7, 30 or 90 days) against the window immediately before it. A topic, entity or category counts once per brief. Momentum is coverage frequency — how often something appears in verified sources — not its real-world market share, revenue or adoption. “Visa appears more frequently in recent coverage” is a claim the data supports; “Visa is gaining share” is not.

A theme needs at least two developments in the current window, and three across both, to get a direction — otherwise it reads “Early signal” or “Insufficient history”. Small samples are shown as raw counts (“4 vs 1”), never as a percentage. The dataset is young; the modules say so where a signal is thin.

Where it stops

  • Coverage depends on what the search API surfaces. A development that is not indexed will not appear.
  • Some sources publish only headlines in their feeds. These are marked, and the model is instructed not to infer beyond them.
  • Analytical judgements in a brief are the model’s interpretation, not sourced statements. They are labelled as such.
  • The system does not reconcile claims against each other over time. A retracted story would remain in the archive.
  • Not every investigated topic produces a brief. Refusal and “insufficient evidence” are recorded outcomes, not errors.

Merchant analyzer

The analyzer is a separate, self-contained tool. A transaction CSV is parsed and analysed entirely in the browser — nothing is uploaded, stored, or sent to a model. Every figure is deterministic: the same file always produces the same result. Approval rate is defined as approved ÷ (approved + declined); technical errors, pending attempts, and post-payment lifecycle events are reported on their own and never change that denominator.