Why the PayIt Deal Should Be Stopped at Toronto City Council
AKA when following procurement rules doesn’t catch the problem
I’ll acknowledge that it is unlikely this deal will be stopped at City Council for a number of different reasons. But I’ll also say that the shape of the problem it represents is highly common in tech procurement, so this is the beginning of documenting it as a case study and for how to mitigate it should it pass. This is a piece written for those that have been following this project. For additional background please see this and this.
UPDATE FEB 3, 2021
Though staff may say vendor lock-in isn’t an issue here, that we can change our minds if this isn’t a good product, the likelihood of lock-in is super high for two reasons:
- This tech goes direct to resident, so once residents start using it to pay for things and it gets normalized at the resident end, it becomes really hard to make the case to switch, and the City will feel it will be making a public admission of making a bad decision.
- This software maps across existing systems, and once you start doing that you begin to build it pretty deeply into processes and architecture. So though theoretically, or perhaps contractually, or from a sales perspective, it is made to sound like it’s not a lock-in, the way IT operates and how governments rarely if ever shift course on these things, makes it highly likely to become lock-in. The history on this is so near to perfect lock-in every time and it’s why governments are such lucrative clients.
Some governments say their biggest innovation successes are getting out of bad contracts. They say that because of how hard it is to pull off.
UPDATE END — Original Piece Below
This deal is of significant financial value. We’re talking tens, and potentially hundreds, of millions of dollars. We’re also talking about a piece of core digital infrastructure — a platform that seeks to be a communications layer between the City and residents for a host of uses in the medium and long term, not only for what its name suggests, which is paying for things. The platform would become a layer that connects disparate internal systems, which means it will have substantial power in terms of long-term technology design and development. Here I seek to lay out the problem with the deal in a linear fashion, and before I do this I’ll share the high level summary:
The problem with this deal is bundling. The City is engaging in a transaction that seeks to procure two distinct products (payment service and city-wide digital platform) at the same time. The way these two parts are brought together is more of a business model than either of its two technology functions, though there is *some* crossover. This is why the approach the City used to look for other bids didn’t work (more on that below). It’s also why it’s important not to accept the results of the recent process followed by City staff, which suggest this can’t be done any other way. That’s not accurate. They may think it’s defensible, which is totally fine, and there are lots of trade-offs ini play, but that’s different.
The history of this deal is critical to the problem we face now, so I’m going to lay it out in a linear fashion:
- PayIt, the vendor in question, started to lobby the City years ago to see if it might be interested in its product. It’s unclear how much lobbying was done prior, but the interaction led to PayIt submitting an unsolicited proposal through the City’s partnerships office. There is an entire other conversation to have about what should have happened at that point, given the bundled nature of the product, but we’ll save that for another day.
- The City and PayIt continued to work together — outside of any contract — co-developing a pilot, and building a relationship. Part of the way PayIt structures its service delivery is that it essentially offers the City a “free” digital platform, and rather than the City paying for it, PayIt takes a percentage of the financial transactions it does with Toronto residents on City of Toronto payments, such as property tax or utility bills. Now, stop here for a moment and understand that through this deal the fourth largest city in North America becomes a surface area for direct transactions between PayIt and residents. This is where the future value of this deal is large. The reason the company can “give away” its software is partially because of how it’s capitalized, and some of that is venture capital. They recently raised a 100 million dollar round. Give away software now and in perpetuity, be able to charge points on fees for a long long time to fund its development indirectly, and in “partnership” with the City.
- After some time of working with PayIt, staff decided to suggest the contract opportunity should be sole sourced. City Staff hired Gartner to do a market assessment of what else was out there, and used that Garner report to support the sole sourcing choice. That report was not made public then and still has not been made public now. When I asked I was told I had to FOI it. When this deal was brought to City Council last year, Council challenged the sole sourcing of the deal. The tool staff then used to address the problem was to seek other bidders through a rarely used process (three times to date in Toronto, since 2008) called a Swiss Challenge. This solution provided little chance at solving the problem, it actually served to replicate it. Here’s why.
- The Swiss Challenge process is one where you use an unsolicited proposal (the one PayIt submitted to the City) to go to market and ask others to compete with it. The problem in this particular case is that asking others to compete with the bid is essentially asking to find other companies that have the same business model as PayIt, it’s not asking for other companies that enable digital payments or other companies that provide digital platforms because the framing is set up as a bundle through the procurement type, both had to be in play. And that no other successful bids emerged from this process should have come as little surprise because the whole rationale for the sole source in the first place was that it was a unique offering. Which, again, is common with tech models and products that understand the government market. But the problem, again, is that this unique offering is a business model, not the actual technologies. And if you tie this all back to the beginning, this was not a technology procurement that the City wrote the requirements for on either front (sales solution or city-wide platform), it was a procurement that was informed by a company that approached the City and found what it will find at every city: legacy IT systems that are disconnected for a number of reasons, and a government that wants a simple solution that is user friendly, one that can improve resident interactions with the City, and facilitate faster payments. The trade-offs often involve accepting the use of proprietary systems, the loss of control that they create, and vendor lock-in once the model gets entrenched. These are all incredibly common in government technology.
- So, when Staff tell Council that no one else qualified, it’s important to understand that this should not have been a surprise. Following all the rules for a Swiss Challenge process to the letter didn’t catch the context and the bundling issue. This then leads to issues relating to fairness, which is the key principle for public tendering. It is both absolutely true that the rules were followed AND that those rules didn’t address the shape of this problem, which is contextual. A third-party fairness assessment can and did confirm the rules were followed and again not pick up on this problem. This all points to a future need to look back to both a) the rules related to the unsolicited proposal and b) the rules related to the decision to pick the Swiss Challenge to deal with it.
- Finally, there is more to be said, but there is definitely an argument to be made that all these trade-offs are worth it for what this deal represents, how it was done, etc. (control vs. efficiency, urgency vs. long-term planning). But from my side, I’d like to offer the considerations again about the size of this deal, and about what it means to potentially get locked into a long-term deal with a vendor to supply a big and important piece of infrastructure (a city-wide digital platform) when the design and model and control of that large infrastructure is front-ended by a company that is all about making payments. The City is in the throes of creating a Digital Infrastructure Plan and there are all kind of controls that should or could be in place for such a platform, including requirements of open code for public money, requirements around control of how the platform works and how to take it in-house over time, etc., so we’re not locked into a platform that is being sold primarily as a payments system, the business model being used to support that, and all the flows from it. It’s difficult to put a dollar amount on the intangible value of long-term public control of our systems, but we should know enough by now that getting locked into proprietary systems for vital long-term functions comes with a raft of problems. Again, I’m not going to argue the reasons that some may think the trade-off of this deal is worth it, but there certainly are some, and there is a complexity level related to the savings and reinvestments of said savings that are mentioned in this all that I can’t even follow. I’m not trying to minimize those. It’s also safe to say that the financial model could be done differently than what is proposed, keeping more money in public control.
- In summary, the way this deal came to be and has continued to move through Council is not ideal on a few levels. In an ideal world, the City and its residents would be planning how this all should work and it would likely look like at least two separate tenders. And if not that, then certainly not a tender that was written in part by the vendor.
- I know there is so much going on at Council this week. I also know the problems raised here needed to be dealt with a lot sooner in the flow of events, so I’m not optimistic anything will be stopped, but this issue of rules not catching a problem is highly common in technology procurement. This is an important case study for other cities, states and provinces, particularly those with large populations, that appeal to this transaction fee model and even moreso for those that have this unsolicited proposals mechanism through partnership offices or innovation offices.
- Finally, it’s so vital to stress that this assessment is being written in an effort to make the process more visible. All of these steps could be taken in good faith by all actors, but this does not mean that given the size and importance of the deal, scrutiny and consideration for alternative approaches shouldn’t also be on the table for discussion. As ever, if everyone is making an informed decision to politically support this, that is fine — but given how hard I find it to even *describe* the problem, that also feels unlikely.
- And truly finally, I’m writing this in significant haste because I’m not highly focused on this issue due to capacity, but also wanted to make sure I wrote at least one focused piece on what I see as the problem. Any errors, omissions, corrections, critique, etc. welcome and I apologize in advance if I’m missing things. The intent is to make sure the issue I see is as least imperfectly legible to others.
