Market scan report template

A market scan report answers one question for a financial institution: which vendors could meet this need, and which few are worth the time of a request for proposal, a demonstration or a pilot. The sections below are the ones a decision maker reads in order. Each has a note on what it is for and a worked example from Example Mutual, a credit union of 180,000 members choosing a loan origination system. A consultancy or a procurement team copies the headings and replaces the example with its own words.

1. Purpose and scope

What it is for. One paragraph on the need, the system or service in scope, the decision the report supports and who makes it. A reader who gets no further should know why the scan was run.

Example. Example Mutual originates home and personal loans through its branches, its contact centre and 240 accredited brokers. Its loan origination system reaches end of support in June 2028. This scan identifies the vendors able to replace it for all three channels, and recommends which to invite to a request for proposal. The decision is the Transformation Steering Committee's, in March 2027.

2. Method and sources

What it is for. How the longlist was built, what counted as evidence, when the market was read and what was left out. Credibility rests here: say which vendor claims were checked against a public source, a reference customer or a demonstration, and which stand only on the vendor's word.

Example. The longlist was drawn from the Vederca vendor registry (lending and origination, vendors operating in Australia), two analyst reports and the committee's own list of vendors already met. Each vendor's product pages, published customer announcements and regulatory filings were read between 1 and 20 October 2026. Capabilities count as confirmed only where the vendor confirmed them in writing or demonstrated them; a mention on a website is recorded as a mention. Vendors with no deployed customer in a deposit-taking institution were noted and kept, but not scored on the operational criteria.

3. The market in brief

What it is for. Four to six short paragraphs a board member can read in two minutes: how many vendors serve this need, how they differ (delivery model, size, home market, who they serve), what has changed in the last two years and what that means for the choice.

Example. Twenty-six vendors sell loan origination software to Australian lenders; eleven operate from Australia and the rest from the United States, the United Kingdom, India and Singapore. Nine are cloud native and sold as a subscription; the others license software the institution hosts, or offer both. Six name a credit union or mutual as a customer. The newest four entered the market since 2021 and sell to brokers and non-bank lenders first. Over the last two years the leading vendors have added broker portals, open banking data for serviceability and AI-assisted document checking; the smaller ones compete on speed of change and price.

4. Longlist

What it is for. Every vendor considered, in one table, so nobody can later ask why a name is missing. Say in one line why each was included or set aside.

Example.

5. Requirements and evaluation criteria

What it is for. The requirements the institution set before reading any vendor material, with their priority (must have, should have, could have), the evidence asked for and how each was assessed. The full list is the requirements register (appendix B and the example below); this section summarises it and states the weights.

Example. Thirty-one requirements were set in the register: twelve must-haves (any vendor failing one is excluded), fourteen should-haves scored 0 to 3 and five could-haves scored 0 to 1. Functional fit carries 50 percent of the score, integration and data 20 percent, security and regulatory compliance 20 percent, commercial and delivery 10 percent. Must-haves are not weighted; they are gates.

6. Evaluation

What it is for. How each longlisted vendor met the must-haves and scored on the rest, with the evidence beside each judgement. A table first, then a paragraph per vendor on what the score hides.

Example.

Vendor A's functional score rests on a demonstration of the branch workflow and a written confirmation of broker accreditation handling; its hardship module was described but not shown. Vendor B's integration score reflects a live open banking connection at its existing mutual customer. Vendor C failed the Australian hosting must-have; it hosts in the United Kingdom and offered an Australian region in 2028, which the committee did not accept as a commitment.

7. Shortlist and rationale

What it is for. The vendors to take to the next stage and why, and the vendors set aside and why, in plain words. This is the section the committee quotes.

Example. Vendors A and B go to a request for proposal. Both meet every must-have, both run in deposit-taking institutions of similar size, and they differ on the question the committee most needs answered: Vendor A's branch and broker workflow against Vendor B's data and decisioning depth. Vendor D is held in reserve: it meets the must-haves but would mean running a second core vendor's suite, which the architecture principles discourage. Vendors C, E and F are set aside for the must-haves they failed, recorded in section 6.

8. Risks and open questions

What it is for. For each shortlisted vendor, what the scan could not settle and what the next stage must test. Risks the institution carries whatever it chooses belong here too.

Example. Vendor A: the hardship module and the collections handover have not been seen; ask for a scripted demonstration. Vendor A has 90 staff; ask how support is staffed in Australian hours. Vendor B: the broker portal is new in 2026; ask for a reference broker and the roadmap for accreditation management. Both: confirm the sub-contractors that deliver any part of the service, and the exit and data return terms, before contract.

9. Indicative commercials

What it is for. How each shortlisted vendor prices (subscription, licence, usage, quote on request) and the ranges quoted, if any, with the basis. Never a number the vendor did not give in writing.

Example. Vendor A prices a subscription per active loan account with an implementation fee; it gave a range on request. Vendor B prices a subscription in tiers by originated volume; it gave an indicative annual figure and a separate implementation estimate. Neither figure is binding and both will be tested in the request for proposal.

10. Recommended next steps and timetable

What it is for. What happens next, who does it and by when.

Example. Issue the request for proposal to Vendors A and B by 14 November 2026 with the requirements register attached; scripted demonstrations in the week of 8 December; reference calls with one mutual customer of each by 19 December; recommendation to the Transformation Steering Committee on 10 March 2027.

Appendix A. Sources

What it is for. For each vendor, the pages, documents, demonstrations and conversations the judgements rest on, with dates. A reader should be able to check any claim.

Appendix B. Requirements register

What it is for. The full register, in the form shown in the requirements register example that accompanies this template.

Requirements register example

A requirements register is the list the institution sets before it reads any vendor material: what the system must do, what it should do, and what evidence will show it. Vendors answer the register in a request for proposal; the evaluation scores against it and nothing else. The example below is Example Mutual's register for a loan origination system, cut to fourteen rows. A full register usually runs to thirty to sixty.

Priorities: a must have is a gate (a vendor failing it is excluded), a should have is scored 0 to 3, a could have 0 to 1. Evidence names what the vendor is asked to produce; how assessed says how the team will read it. The regulatory rows name the regime that applies to Example Mutual as an Australian deposit-taking institution; a lender in another country replaces them with its own regimes.