Five upright document folders in a row on a concrete surface, one black and the rest grey and white, with a single red sheet showing in one of them

Five artefacts to ask for before you sign

What to ask a product partner on the first call, and how to read the answers

By Milana LeideniusCPO, Alty5 min read

Most agencies look the same from the outside. We do too.

We all know what a selection process looks like: a deck, two reference calls, a scoring matrix. How do you learn from any of that how a team behaves in month four, when the date has moved and somebody has to decide what gets cut?

I'm not the one running these selections. I'm the one answering them. Fifteen years of building products for banks means I've sat on the supplier side of a lot of procurement and watched which questions do real work. Most don't. Every supplier has a prepared slide for "how do you handle change requests."

What nobody has a prepared slide for is an artefact. Answers describe how a team would like to work. Artefacts are what the last engagement actually produced. All five below already exist at a competent supplier, because making them was part of doing the job.

The five

  • A decision log. What was chosen, what was rejected, why. If you ask for one thing on this list, ask for this. Six months after the supplier has gone, this conversation happens somewhere in your team: "Why does the limit check run before the balance call?" — "I don't know, it was like that when I joined." — "Who decided it?" — "Someone at the agency, I think." Either the reasoning was written down while it was fresh, or it gets reconstructed by people who weren't there.
  • A degraded-state specification. What the interface does when the backend is slow, partly available, or down: what the customer sees, what they can still do, what gets queued. Portfolios show the product working. Most of production is the other states. Unfortunately this is also the part nobody prepares a slide for, which is why it sorts suppliers faster than anything else here.
  • The named delivery team, with current allocation. Who is assigned, at what percentage, and what else they carry during your dates. Undoubtedly the pitch team is the strongest team a supplier has — that is why they are in the room. Ask about the other one. Eight weeks out this should be answerable on the call; if it isn't, ask again a week later and see whether the names changed.
  • A handover pack from a completed project. The actual material a previous client received on the final day. Redacted is fine. What you are buying is your team's ability to carry the work forward once we've gone, and that is close to impossible to assess in a pitch. Assess it on somebody else's leftovers instead.
  • Exit terms, in writing. Environments, credentials, repositories, documentation — what happens to each on termination, including termination for convenience. Alongside it, who owns the code and the assets, under which licence, from the day the contract ends. Nobody enjoys negotiating the ending at the beginning. Your risk function will ask you for it anyway, because exit planning is an explicit expectation under PRA SS2/21.

One more question, which isn't an artefact: ask which parts of the work sit with another firm or with contractors. Onward subcontracting is a supervisory concern in its own right under SS2/21, and an undisclosed chain becomes your problem rather than your supplier's.

Reading the answers

Some refusals are correct. Confidentiality genuinely prevents sharing an unredacted handover pack. A supplier who explains the constraint and offers a redacted version is doing the right thing.

Watch instead for agreement followed by silence. "We can put something together for you" means it doesn't exist and is about to be written for your benefit. What you would be evaluating then is their ability to produce a document under deadline, which is not the thing you are buying.

Two of the five carry more weight than the other three. The decision log tells you whether a supplier reasons in a way your team can audit after they have gone. The degraded-state specification tells you whether they have shipped somewhere failure had consequences. Most gaps can be closed during an engagement. Those two are either already there or they are not.

Why this matters more in financial services

Accountability does not move with the work. The FCA puts it plainly: a firm stays responsible and accountable for the regulatory responsibilities attached to its outsourcing and third party arrangements, and none of that can be delegated away (FCA, Outsourcing and operational resilience). The same holds for arrangements that fall outside the outsourcing definition — those still sit inside the rules on governance, risk management, systems and controls.

One date worth holding on to. On 18 March 2026 the FCA published new operational incident and third party reporting requirements, with twelve months to prepare before they take effect on 18 March 2027 (PS26/2). Arrangements you enter into now will be documented under that regime.

Before you ask us anything

Before publishing this I checked that we could produce all five ourselves, on request, inside two days. If you want to test that, ask.

There is a longer version of the list — twenty-five items across team, continuity, failure, scope and compliance evidence. Same offer: ask and I'll send it.

Understand how we work

Sources

Outsourcing and operational resilience — FCA. Firms remain accountable; non-outsourcing third party arrangements still sit within governance and systems-and-controls rules.

SS2/21 Outsourcing and third party risk management — PRA, first published 29 March 2021. Due diligence, sub-outsourcing, data security, business continuity and exit plans.

PS26/2 Operational incident and third party reporting — FCA, published 18 March 2026. New reporting requirements in force 18 March 2027.

Applicability varies by firm type and by how an arrangement is classified. PRA material applies to PRA-regulated firms; FCA Handbook provisions apply according to the detailed application rules in SYSC. This list is a starting point for a conversation with your own risk function, not a substitute for it.