Market scan

What is a market scan, and how do you run one?

A market scan finds every vendor that could meet a need and narrows them to the few worth a request for proposal. Procurement teams run them before a tender; consultancies run them for clients. This page sets out the method, where scans go wrong, a template to copy, and the Fintech Market Scan: the financial services software landscape in numbers from the Vederca registry.

What a market scan is

A market scan (government procurement guides call it supply market analysis) is the first stage of choosing a system or a service: a structured read of who sells it, how they differ and which of them fit an institution's requirements well enough to be asked for a proposal. It ends in a report with a longlist, an evaluation against stated requirements and a recommended shortlist, usually three to five vendors. It is not a tender: no vendor is asked to commit, and the institution commits to nothing. It is the work that makes the tender small, fast and defensible.

In financial services the scan carries extra weight. The buyer is regulated, so the requirements include the regulator's outsourcing, resilience and data rules; the systems run for a decade; and the vendor field is wide and uneven, with global suites, regional specialists and new entrants side by side. A scan that reads the whole field, in the vendors' own words, is how an institution avoids choosing from the three names it already knew.

How procurement teams and consultancies run one

  1. Set the requirements before reading a vendorWhat the system must do, should do and could do, with the evidence that will show it, in a requirements register. The regulator's rules go in as must-haves. Weights are agreed now, so no vendor's pitch moves them later.
  2. Build the longlistEvery vendor that sells into the category and the market: a registry such as Vederca's, analyst lists, peer institutions, the vendors already met. Record why each is in. A longlist of twenty to forty is normal; nobody is excluded yet.
  3. Read the market in the vendors' own wordsProduct pages, customer announcements, filings and demonstrations, dated. A capability counts when the vendor confirms it or shows it; a phrase on a website is a mention and is recorded as one.
  4. Ask the field a short set of questionsA request for information to the longlist, or the part of it that could plausibly fit: ten to twenty questions on the must-haves, delivery, hosting, customers like the institution and how the vendor prices. Answers are evidence; silence is an answer too.
  5. Evaluate against the registerGates first: a vendor failing a must-have is out, and the report says which one. Then scores on the should-haves and could-haves, each with the evidence beside it, so a reader can disagree with a score and see why it was given.
  6. Shortlist, with the rationale and the risksThe three to five vendors to take to a request for proposal, why each is there, who was set aside and why, and what the next stage must test for each. Indicative commercials by pricing model, never a number the vendor did not give.
  7. Write it so the decision maker can read it in ten minutesPurpose, method, the market in brief, the table, the shortlist, the risks, the next steps. The report template gives the headings and a worked example.

A consultancy runs the same steps for a client, with two differences: the client signs off the requirements before the longlist is read, and the report is written in the client's name. Vederca's procurement portal puts each client on record for exactly this (see market scans for consultancies).

Where market scans go wrong

  • The longlist is the vendors the team already knew. A scan that starts from three names ends with one of them. Read the whole category first; the registry lists every vendor serving financial institutions, by category and by country.
  • Mentions are read as capabilities. A website that says "AI-powered" or "real-time" has said nothing yet. Score what the vendor confirmed or showed; record the rest as mentions to test.
  • Requirements are written after the demonstrations. The best demonstration then writes the requirements. Set them first, weight them first, and keep the register under version control.
  • The regulator's rules arrive at contract. Outsourcing, resilience, information security and data residency obligations belong in the must-haves, where a vendor that cannot meet them is excluded early and cheaply.
  • Price is compared without a model. Subscription, licence, usage and quote on request do not compare on one line. Model the institution's volumes first; compare total cost over the term.
  • The report cannot be checked. Every judgement needs its evidence and its date beside it. A reader who cannot trace a score will not trust the shortlist.

How Vederca's managed market scan fits

Vederca runs the scan for a procurement team or for a consultancy's client: the team sets its requirements in the portal, Vederca takes them to up to 15 vendors from the registry, every response is evaluated against the evidence in it, and the team receives a report recommending a shortlist. One fixed fee, quoted first, paid by the procurement team; vendors list and respond free, and no vendor can pay for a position. The registry, the briefs and the pages under this hub are free to read without an account.

Managed market scans for financial institutionsCreate a free procurement account

The market scan pages

Free documents and tools

How to run a market scan, by category

The vendor lists

  • Vendor registryEvery software vendor serving financial institutions, by category and by country.
  • Product registryEvery product, in its vendor's own words, with the capabilities it confirms or mentions.
  • Core banking software vendorsThe category pages: the largest by named customers, the newest, the table, the questions.
  • Market briefsThis week in every category, from the news, every Monday.