Skip to content
ADVISORY

THE WORK

Two cores. Strategy and GTM. Data and AI. Everything else is how that work shows up in a live payments business.

CORE 01

STRATEGY & GTM

  • Which vertical
  • Which product
  • Which partners
  • Which markets
  • What you will not do

CORE 02

DATA & AI STRATEGY

  • What you must measure
  • What you can predict
  • What a model may decide
  • Build / buy / ignore

One operating business

The two advisory cores — Strategy and GTM, and Data and AI strategy — converge on a single live payments business.

CORE 01 — STRATEGY & GTM

WHY NOW

Processing is getting cheaper. Value moves to the edges — merchant relationship, rails, verticals, who holds licence/risk/customer. GTM as “more sales” or a generic co-brand process loses to operators who already chose a lane.

WHAT

Funded choices — vertical, product, partners, markets, no-list. Niche vertical GTM. Commercial/corporate card programmes. Partnership structuring. Product→market when product exists and revenue path does not.

VS GENERIC / BIG 4

Decks and programme offices vs sitting with operators. Principal built DS/analytics inside processors, then advised the same class of company. Strategy is data-literate by construction.

LEAVE WITH

GTM commercial can run and board can recognise.

NOT FOR

Merchants shopping PSPs. Matching. Awareness packages.

CORE 02 — DATA & AI STRATEGY

WHY NOW

Auth/fraud/decisioning are not side projects. Schemes put models in the auth path. Archive-data competitors lose margin and false positives together. Boards want AI roadmaps while warehouses cannot explain yesterday’s auth dip.

WHAT

Data scientist principal. Maturity descriptive→predictive→prescriptive. Unified metrics. AI/ML for auth/fraud/decisioning with latency, scheme rules, false positives named. Build/buy/ignore architecture.

VS GENERIC AI / PAYMENTS-ONLY

AI shops ignore transaction lifecycle. Payments shops stop at slides. We bridge: built fraud scoring, auth optimisation, payment intelligence in production; now advise what ships so CRO and CTO share one plan.

LEAVE WITH

Fundable AI/data plan — use cases, architecture, build-vs-buy, path to authorisation not a lab.

NOT FOR

Vendor bake-offs as strategy. Model staff-aug. We design; their team builds.

PATTERNS — PERFORMANCE. BUILD. NOT A MENU OF FOUR PRACTICES.

PAYMENTS PERFORMANCE: when the question is where money is leaking. Auth leadership, multi-platform routing, impact in euros using the client’s own data. We do not publish other people’s numbers.

BUILD & LAUNCH: when the question is standing up issuing or acquiring without a five-year science project. Programme design. Vendor orchestration: scheme, processor, security.

Merchant

Checkout, conversion, cost of acceptance

Gateway / PSP

Routing, retries, orchestration

Acquirer

Auth performance, scheme fees, risk

Scheme

Interchange, mandates, licensing

Issuer

Decisioning, fraud models, approval

Payments performance

Build & launch

Payments performance work runs from the PSP down to the issuer decision. Build and launch work sits across acquiring and issuing programmes. Neither lives at a single layer, which is why the questions are rarely answered at one either.

HOW AN ENGAGEMENT RUNS

  1. 01

    Strategy conversation

    Fit, constraint, whether we continue.

  2. 02

    Written scope

    Problem, decisions, deliverables, time.

  3. 03

    Work

    We advise. Operators execute. We stay for the decisions that compound.

Each step gates the next. The first conversation can end the process, which is the point of having it first.
BOOK A STRATEGY CONVERSATION