Scottish Government

Payments platform prototype design and build

Incomplete applications

14
Incomplete applications
11 SME, 3 large

Completed applications

33
Completed applications
24 SME, 9 large
Important dates
Opportunity attribute name Opportunity attribute value
Published Thursday 29 November 2018
Deadline for asking questions Thursday 6 December 2018 at 11:59pm GMT
Closing date for applications Thursday 13 December 2018 at 11:59pm GMT

Overview

Overview
Opportunity attribute name Opportunity attribute value
Summary of the work We want you to help us design and deliver a prototype to test if it is feasible to build a standardised payments solution capable of being linked to a diverse set of Public Sector client organisations, and connecting to a range of existing commodity payments services.
Latest start date Monday 4 February 2019
Expected contract length 3-4 months
Location Scotland
Organisation the work is for Scottish Government
Budget range The budget is up to £300,000, including VAT

About the work

About the work
Opportunity attribute name Opportunity attribute value
Why the work is being done There are around 140 Scottish agencies within the Scottish Government (SG) and Public Sector which, currently, are separately responsible for maintaining and modernising their inbound and outbound payments systems.

Volumes of payments made and received by both existing and new powers to be devolved to Scotland are set to rise, and the expectation is that this will increase to over 10 million payments per annum. We are undertaking exploratory work to determine if it is possible to create a payments service for SG.
Problem to be solved 1) We want you to help us design and deliver a prototype to test if it's feasible to build a standardised payments solution capable of being linked to a diverse set of Public Sector organisations, and connecting to a range of existing commodity payments services.

2) Provide recommendations and options (to support our business case) on how the service could be scaled and managed, to include technology options, costs, team structure and service models.

The solution should be based on loosely-coupled, component-based, secure & sustainable technology and existing commodity services, and adhere to SG’s Service Design Principles/Digital First Service Standards.
Who the users are and what they need to do At this stage, users are predominantly internal.

● As a citizen or business, I need to be able to pay/receive money to/from the Scottish Government and wider public sector
● As a public sector organisation, I need to be able to pay/receive money to/from business and citizens
● As a public sector organisation, I need to be able to plan, execute and measure financial transactions
● As the Scottish Government, I need to be able to respond to increasing scale and complexity of payments as devolved powers change, and receive consistent management information to carry out financial administration
Early market engagement
Any work that’s already been done While some material already exists – such as case studies and reports from other linked projects, desk research and stakeholder interviews – it is important to understand this project is designed to inform our future approach.

Work already underway includes activity to understand the existing landscape, user needs and business processes, and test a number of technological assumptions.
Existing team We have a small core team in place, supported by subject matter experts and stakeholders from other Scottish Government departments, agencies and public bodies. Our combined skillset includes product ownership, business analysis, user research, business change/transformation, and technical architecture.

We are working with two other suppliers who are providing strategic input on commercial models to support how we engage with the market going forward, and a partner to help us develop insights and analysis from other governments and public sector organisations. All suppliers are expected to share knowledge and work together.
Current phase Not started

Work setup

Work setup
Opportunity attribute name Opportunity attribute value
Address where the work will take place The work will take place in the Scottish Government's offices at Victoria Quay, Edinburgh
Working arrangements We expect you to co-locate at our offices in Edinburgh, and form part of a multidisciplinary agile team, ideally on a full-time basis but we will accept at minimum 3 days a week.
Security clearance BPSS

Additional information

Additional information
Opportunity attribute name Opportunity attribute value
Additional terms and conditions

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Skills and experience
Opportunity attribute name Opportunity attribute value
Essential skills and experience
  • Ability to begin work by latest start date (Yes/No)
  • Ability to deploy a multidisciplinary team and co-locate in Edinburgh for the project duration (Yes/No)
  • Provide examples of successful design and delivery of loosely-coupled, component-based technology projects involving complex integrations (30%)
  • Demonstrable experience of iteratively designing secure and sustainable high-volume transactional digital services based on user needs (25%)
  • Provide examples of where you’ve provided information and evidence to support the scaling and management of a live service (20%)
  • Demonstrable experience of agile delivery within government or other relevant organisations (15%)
  • Knowledge of payments service technology (10%)
Nice-to-have skills and experience Experience of delivering projects that conform to Scottish Government’s Digital First Service Standards (https://resources.mygov.scot/standards/digital-first/) or GOV.UK’s Digital Service Standard, or other relevant technology assurance

How suppliers will be evaluated

How suppliers will be evaluated
Opportunity attribute name Opportunity attribute value
How many suppliers to evaluate 6
Proposal criteria
  • Technical solution (40%)
  • Approach and methodology (20%)
  • How the solution will meet user needs (20%)
  • Team structure (20%)
Cultural fit criteria
  • Demonstrate experience of working as part of a team within a complex organisation, outlining your style and approach to challenging the status quo (25%)
  • Provide an example of working in a user-centred design environment (25%)
  • Provide an example of where you’ve had to be agile and flexible to changing or uncertain requirements (25%)
  • Provide an example where you have worked collaboratively in a multi-disciplinary team with other suppliers (25%)
Payment approach Fixed price
Assessment methods
  • Written proposal
  • Case study
  • Work history
Evaluation weighting

Technical competence

60%

Cultural fit

20%

Price

20%

Questions asked by suppliers

Questions asked by suppliers
Supplier question Buyer answer
1. Has the buyer explored the standardised payments solution capable of being linked to a diverse set of Public Sector client organisations, and connecting to a range of existing commodity payments services delivered by GOV.UK as a service free of cost to use?
https://www.payments.service.gov.uk/
Yes we have, and GOV.UK Pay is very much part of our considerations. However for this feasibility study we are focusing on a wider remit than what GOV.UK Pay currently covers - addressing both inbound and outbound payments.
2. Do you have any particular technical requirements for the frontend, backend, and the cloud platform?

For example;.NET/PHP/JAVA for backend, Angular/React/Bootstrap (GDS Toolkit) for frontend, and GCP/AWS/Azure for the deployment.
At this stage we are completely open to the technology used, and the current proposed architecture is technology agnostic.
3. Can you provide more clarity into the team composition in terms type of skills and expertise expected from a supplier applying for this? The composition of the team proposed is down to the tenderer who will be required to deliver the outcomes as defined in the specification document (provided at the next stage).

However, we would envisage the team has following abilities:
• Solutions design
• Lead/supporting developers
• Business analysis
• Project/contract management working alongside Scottish Government team

Regarding the make-up of the team, it will be up to tenderers to detail how they would address the above-mentioned abilities.
4. Do you have a technology/tool stack in mind for this prototyping activity? At this stage we are completely open to the technology used, and the current proposed architecture is technology agnostic.
5. Is there a specific reason why all team members need to be co-located?
That is, is there is a business reason that may make an operational model with a few key resources being co-located whilst most of the resources may work remotely, not feasible?
The most efficient and rapid progress of an agile team happens when all team members are in the same space, hence our requirement for a co-located team with a minimum 3 days a week in our Edinburgh office.
6. Please can you clarify if the £300k budget range is to exclude or include expenses? The budget of £300k includes all travel expenses for the purposes of locating the team in Victoria Quay, Edinburgh. If the Scottish Government requires team members to go to a different location, then expenses will be paid for in accordance with current Scottish Government expenses policy.
7. Please can you clarify whether you expect one supplier to submit the whole team for this project? It is up to the tenderers to decide whether they submit their bids as a single entity or as a consortium, as long as their bids address all of the outcomes defined in the specification document (provided at the next stage) and follow the Digital Marketplace guidance on subcontracting and consortia.
8. What roles do you foresee needing to augment the existing team? The composition of the team proposed is down to the tenderer who will be required to deliver the outcomes as defined in the specification document (provided at the next stage).

However, we would envisage the team has following abilities:
• Solutions design
• Lead/supporting developers
• Business analysis
• Project/contract management working alongside Scottish Government team

Regarding the make-up of the team, it will be up to tenderers to detail how they would address the above-mentioned abilities.
9. We not wish to tender for this contract as we cannot offer the total solution described but would like to know if there is scope to be considered as a subcontractor to the supplier you choose if considered relevant? We ask as the Payment Exception Service we run that is shortly to be implemented by SG following successful deployment by DWP earlier this year. This service has recently been enhanced to allow payments represented by our Secure Digital Voucher service to be made in cash in retail locations or deposited to citizens bank accounts. If you are interested in this engagement, you may submit joint bids (following the Digital Marketplace guidance on subcontracting and consortia), but each bid will have to respond to the full outcomes as defined in the specification document (provided at the next stage).

We will publish an award notice when we award the contract for this requirement, which will provide details of the successful supplier should you wish to use that to contact them.
10. Is the budget mentioned to cover the equivalent of a GDS Alpha stage? Or is it not tightly wedded to the Discovery/Alpha/Beta approach? The project forms part of a feasibility study where we are prototyping key features of a payments solution to provide a proof of concept, and shape our knowledge and understanding.

From a delivery perspective we will be closely following agile principles outlined in the GOV.UK Service Manual.
11. Has the authority considered the use of the GDS payment platform to meet the requirements? If so, would you please advise to what extent will the prototype and any live solution make use of this existing platform. If the authority does not intend to use the GDS payment platform would you please advise why this is the case? The Gov.uk Pay platform will be evaluated during the feasibility study and we are currently engaging with our colleagues within Government Digital Service (GDS). GOV.UK Pay integration may be delivered at prototype stage, however this decision is still to be determined. The specific learning the team wishes to gain from the prototype delivery is integration with a payment service provider.

Gov.uk Pay currently manages inbound payments. As the scope of our feasibility study is for all types of payments we will necessarily look for complementary solutions also, for prototype and for live.
12. Has a discovery phase been undertaken for this piece of work? If so, who undertook this? Formal discovery has not been conducted, and the feasibility study and prototype is the first phase of work on this project.
13. Will the buyer be responsible for covering any license costs associated with tools used (such as tools for team collaboration)?
Will the buyer be bearing any costs related to hosting costs of development and testing environments.
The buyer has already chosen collaboration tools (e.g. JIRA/Confluence), and licences have already been acquired. Hosting costs for development and test in prototype are expected to be covered by the supplier.
14. Is it envisaged that the Prototype will form the basis of the final production software build? (or will this be used to scope a full system build) The prototype is expected to provide the team with learning and insights for potential future phases, and components delivered over the course of prototyping activities may well be reused. Alongside prototyping activity, options appraisals are being conducted including, but not limited to, service options, delivery options and technology options.
15. As a Fixed Price project, how do you anticipate the acceptance criteria be set to confirm that the scope has been delivered? (Have you defined the MVP?) The success of the project will be measured against a set of outcomes which are defined in the statement of requirements, available at the next stage of this tender process.

An MVP for the service has not been defined at this stage, but a set of functional and non-functional requirements are detailed in the statement of requirements document.
16. Would you define the project as comparing payment platforms, or to recommend how to develop a bespoke payments platform for the Scottish Government, or to integrate a platform that has previously been selected? (or other?) At this stage nothing has been specifically defined. We are expecting to integrate a certain number of Payment Service Providers (PSPs), which will be evaluated against each other for best-fit, however the overarching delivery model is yet to be defined.

The team will also evaluate what the best delivery options (build, buy, rent, re-use) are for the future.
17. Do you see the payments platform as a system integration (of set previously selected vendor products), or to design a stand along system to manage payments? At this stage nothing has been specifically defined. We are expecting to integrate a certain number of Payment Service Providers (PSPs), which will be evaluated against each other for best-fit, however the overarching delivery model is yet to be defined.

The team will also evaluate what the best delivery options (build, buy, rent, re-use) are for the future.
18. Can you clarify if we're looking at technical scaling and management of servers, or scaling and management of business processes, or both "Provide examples of where you’ve provided information and evidence to support the scaling and management of a live service"? This question relates to the “Problem to be solved” section, where the ask is for a supplier to “Provide recommendations and options (to support our business case) on how the service could be scaled and managed, to include technology options, costs, team structure and service models.”
19. Can you provide details on the stakeholder interviews, the output of these, and if you expect further stakeholder interviews to be required? Stakeholder interviews are in the process of being conducted, and the team is currently gathering information from a range of Scottish public sector organisations. As these insights have not yet been collated, we cannot share this at this stage.

Further interviews and user research to be conducted as the project progresses, however this will largely be conducted by the Scottish Government team who will share insights with the supplier on an iterative basis.
20. Have you selected a banking partner, or will the evaluation include the selection of a banking payments platform? This determination will be made during the project when the supplier has joined the team.
21. Do we need to consider training and roll out of the final system? At this stage, we need to be able to size the task of training and roll out for the purposes of the business case, not deliver it.

However, we will need to be able to take ownership of the prototype to ensure that the knowledge acquired remains within the Scottish Government, and in this sense, knowledge transfer needs to be taken into consideration (largely through the delivery of relevant documentation).
22. Which of the multiple payment channels do you expect to be included in the prototype and broader evaluation? (channels to receive money include web/paypal, credit card, cash, cheque, bacs, chaps etc. All payment channels will be considered as options which will need to be evaluated for the long term (broader evaluation).

For the purpose of the prototype a selection of these will be sufficient, however this selection will need to be used across multiple channels in order to test routing capability.
23. How mature is the understanding of the public sector and private individual user base (140 are identified)? We can confirm that we have a detailed understanding of a range of public sector and private individual user cases within this phase of the project. User research and insights will continue to evolve as the project progresses.
24. As not all commodity payment services are included in the Prototype, for those outside the "range of existing commodity payments services" how do you anticipate these services are evaluated? This evaluation and determination of the services which are inside and outside the range will be made during the project after the supplier has joined the team.
25. Have you identified a subset of the "range of existing commodity payments services" to be included in prototype, or will this determination be made during the project? This determination will be made during the project when the supplier has joined the team.
26. The desire to test if it's "feasible to build a standardised payments solution". Can we confirm if the feasibility criteria are defined (for example – in agile we term this the definition of ready / done). The feasibility study aims to determine what the service should look like and how it should be operated (in this sense you could equate this to a 'definition of done').

We will also evaluate whether it is feasible to deliver this service in a way which delivers maximum value to the public sector.

We have defined criteria against which we will be assessing the success of the prototype, however these are expected to be different from the evaluation criteria we will be using to assess a live service.
27. We are developing a prototype – is it the intention that the prototype processes real transactions, or runs test transactions? The focus of the prototype will be to test our hypothesis including against commodity test environments. We anticipate that a suitable proportion of small value tests will be processed as real transactions.
28. 1. What payment methods are you looking to accommodate for both incoming/outgoing payments
2. From what accounts would the monies be distributed to and from.
Would the system only be responsible for distribution of monies and not the account of balances etc?
3. What type of distributions would you see this system accommodating? The brief is vague and could be interpreted as anything from benefits through to farming subsidies.
4. Typically a prototype is built to address some key proofs of concept.
Have they been identified at this stage? Are they operational considerations around management of funds and security?
We are at an exploratory stage, looking to produce a robust business case and specifically at the feasibility of a unified payments platform service. In terms of the prototype, we are collecting information from a diverse set of Public Sector organisations, and assessing what payment types could possibly be integrated and looking to design a solution to suit. A small selection of payment types and organisations, to be decided upon with the partner, will be tested within the prototype development.
29. "Provide examples of successful design and delivery of loosely-coupled, component-based technology projects involving complex integrations"
There is a 100 word limit. Only room for 1 example. Officially, buyers cannot discriminate between sellers providing 10 examples and 1. So several questions:
1. Is the aim for sellers to demonstrate they have a breadth of experience? In which case the write up quality of each will be low.
2. Would you prefer to have a high quality descriptions of what happened? Then only room for 1 example
3. Would you evaluate linked documents? So high quality, detailed description given for multiple examples.
The format and word limit of responses is determined by Digital Marketplace, however we would definitely favour a clearly expressed, evidence-based individual example over a list of unsubstantiated examples.

We can’t evaluate linked documents; detailed evidence will be sought at the next stage from those tenderers who are successfully shortlisted.
30. Would you please advise how this work relates to the previously issued tender in September “Cross Government Digital insights’ which focused on the payments platform. Who was the successful tender for this piece of work?” The Cross Government Digital Insights project is referenced in the 'existing team' section where we talk about "a partner to help us develop insights and analysis from other governments and public sector organisations". It is running concurrently to, amongst other things, support delivery of a robust business case, and influence/validate development of this prototype.

The project is being delivered by Public Digital.
31. Can you please provide further details of the envisioned internal milestones during the 3 -4 month period for evaluating feasibility with stakeholders of the product being developed by the selected supplier? Specific detail will be determined on a sprint-by-sprint basis, however we anticipate having regular touchpoints with users, and input from decision-makers/key stakeholders at regular intervals via our agreed governance structure.
32. Although the this is described as a prototype, the description sounds closer to a development of a proof of concept that represents a selected subset of requirements to create a minimum viable product, that will be used to test feasibility. Is this understanding correct? Broadly. The prototype’s purpose is to prove the feasibility of our proposed approach, and the primary objective is to demonstrate payments can be made and taken based on our current technology assumptions and understanding of user/business needs.

We would perceive an MVP to be more deployment-ready, but realise that terminology can be subjective in this area.