Back to Industry insights
Built for launch, or built for scale?
The question card programmes should ask first
The Thredd Team
When a fintech chooses the infrastructure behind a new card programme, the decision usually centres on the next few months.
How quickly can we go live? Does the platform support what we need today? How difficult will the integration be?
All reasonable questions. But a card programme rarely stays as it was at launch.
Volumes increase, products expand and new markets open. Fraud controls need to evolve. Digital wallets, tokenisationand new ways of moving money become relevant. What started as a relatively contained programme becomes a more complex operation.
The infrastructure underneath has to evolve with it.
That means evaluating a processing partner against more than the requirements sitting in today’s product roadmap. The harder test is whether the same infrastructure can support what the business wants to become.
To a cardholder, a payment appears straightforward.
Behind it sit authorisation, scheme connectivity, clearing and settlement, fraud controls, authentication, tokenisation, card lifecycle management, reconciliation, regulatory reporting, disputes and other services that need to work together reliably.
Most create little visible differentiation for the customer. They can still consume a significant amount of engineering and operational effort.
Consider a fintech launching a debit card in one market. The initial processing model may be relatively contained. Add a credit product, digital wallets and expansion into a second regulatory region, and the programme can suddenly require several additional integrations, operating processes and commercial relationships.
The complexity does not come only from building infrastructure yourself. It also comes from assembling it.
Specialist providers have an important role in payments. A fintech may have good reasons to choose a particular fraud platform, authentication service or money movement provider.
The problem starts when every new requirement becomes another system the fintech has to connect, test and manage.
That creates an integration tax: the continuing engineering, operational and commercial cost of maintaining the connections between providers.
It includes security reviews, testing, vendor management, support, reconciliation and change management. When something fails, someone also has to establish which dependency caused the problem and who is responsible for fixing it.
A wallet integration that works well in isolation can still add another dependency to the wider programme. The same is true of fraud, authentication or reconciliation. None of those decisions needs to be wrong individually for the combined operating model to become difficult to manage.
Integrated services therefore create value even when the underlying capability is not unique. If a service already works within the processing environment, the fintech has one less standalone integration to own.
Growth should not require the fintech to add another vendor every time the programme develops.
Infrastructure has two costs.
The first is getting it built or implemented. The second is keeping it resilient, compliant and current as the programme changes.
The second cost is easy to underestimate at launch.
A business entering another market may need to accommodate different regulatory requirements, scheme processes, fraud patterns and operational workflows. Adding credit introduces a different set of servicing and risk requirements. Higher transaction volumes place different demands on resilience and support.
The consequence is commercial as well as technical.
If launching in another market requires a new processor, new integrations and another operating model, expansion becomes slower and more expensive just when the business is trying to accelerate it.
The same applies to product development. A proposition that depends on months of processor change requests can turn a market opportunity into a roadmap item.
Every fintech has finite engineering, product and operational capacity.
Time spent maintaining infrastructure and resolving dependencies cannot be spent on the parts of the proposition customers can see: onboarding, controls, rewards, customer journeys or entirely new products.
That does not mean fintechs should outsource everything underneath the product. Some capabilities genuinely differentiate the business and should remain under its control.
Fintechs should keep control of the capabilities that differentiate the proposition, while avoiding unnecessary ownership of infrastructure that simply needs to work reliably.
Processing infrastructure needs to be resilient, secure and adaptable. Owning more of it does not automatically make the proposition more distinctive.
The limitations of infrastructure often appear gradually.
Perhaps higher transaction volumes expose a performance constraint. A new geography requires functionality the platform cannot support. Adding a product needs extensive custom work. Fraud controls become harder to adapt, or a new service does not fit cleanly into the existing stack.
At that point the fintech either operates within those constraints or changes the infrastructure underneath them.
Migration is sometimes the right decision. Strategies, technologies and markets change.
But infrastructure selected with the next stage of growth in mind makes an avoidable migration less likely.
That is why the buying decision needs to account for the roadmap beyond launch.
Issuer processing still depends on getting the fundamentals of authorisation, clearing and settlement right. But modern card programmes increasingly connect those fundamentals with fraud, authentication, tokenisation, wallets, credit and different ways of moving value.
A processor can therefore remove more complexity by helping those capabilities operate together rather than leaving the client to orchestrate every connection.
This is an important part of how we think about the role at Thredd.
Our platform brings debit and credit together within the same processing environment, alongside value-added services that clients can adopt as their programmes develop. The objective is not to make every technology decision on a client’s behalf. It is to reduce the amount of underlying infrastructure they have to assemble and manage themselves.
Scheme changes, implementation dependencies and local operating requirements still need people who understand them. Our implementation and account teams work alongside clients as programmes launch and evolve, because removing operational complexity requires more than providing an API.
There will still be cases where a specialist external provider is the right answer. An integrated processing model should not restrict that choice. It should stop each new capability from creating unnecessary complexity around it.
A feature checklist tells you what a platform has. It does not tell you how much work the platform removes.
When evaluating a processing partner, ask:
Can the platform continue to perform as transaction volumes and product complexity increase?
Who takes responsibility for scheme mandates and regulatory change?
Can fraud, authentication, tokenisation, wallets and adjacent services work within the wider processing environment?
Can you enter another market without assembling another technology stack?
Can you add products without replacing the infrastructure underneath them?
How many vendors, integrations and operational dependencies will your own teams still need to coordinate?
Capability breadth only matters if it reduces the amount of infrastructure the fintech has to manage itself.
Fintechs can own much more of their infrastructure than they need to. The better test is whether owning it helps them compete.
So consider the programme at ten times its current size.
If the business had ten times the transaction volume, operated in five more markets and offered several additionalproducts, would the infrastructure underneath make that growth easier or harder?
A processing partner should do more than get the first programme live.
The infrastructure should support the next stage of growth, not become the constraint that forces another migration.
Speak to our team about what operational readiness looks like for your specific card program.
