Selling software to a bank: what their regulators make them do to you
When a bank, insurer, or licensed financial services provider buys your software, you are not just negotiating with their procurement team — you are negotiating with their regulators by proxy. The FSCA and the Prudential Authority hold regulated institutions to expectations on outsourcing, third-party risk, and operational resilience, and an institution cannot discharge those obligations unless its vendor contracts give it the rights its regulators expect it to have. The result: a fintech-sized vendor receives an enterprise-grade contract pack, and most of it is genuinely non-negotiable in substance. Knowing which parts are structural and which are over-reach is the negotiation.
The security schedule arrives first — usually before the contract, as a vendor due-diligence questionnaire. Expect contractual commitments to a defined control framework, security certifications (ISO 27001 is the common ask), regular penetration testing with results shared or summarised, and incident-notification obligations on tight clocks (24–72 hours is typical). Commit only to controls you actually run: a security schedule is a warranty, and a gap between paper and practice is where post-breach liability lives.
Audit and regulator access goes further than commercial deals: the institution's internal audit, its external auditors, and — because its regulators expect it — the regulators themselves may require access to records and, in some cases, systems relating to the service. You cannot delete the clause; you can scope it. Reasonable notice, defined frequency for routine audits, cost allocation for anything beyond an annual cycle, supervised access, and hard protections so that an audit never exposes other clients' data or your source code.
Business continuity and exit are paired obligations: a tested BCP/DR capability with defined recovery objectives, and a documented exit plan — data return in usable formats, transition assistance, and continuity of service during migration to a successor. The exit plan is where vendors give away margin: scope transition assistance in hours, price it, and time-limit it. Sub-outsourcing controls complete the set — consent or notification rights over your subcontractors and hosting changes, which can quietly hand the customer a veto over your infrastructure roadmap. Push for notification-plus-objection over hard consent, and carve out like-for-like changes within your existing cloud environment.
Where to push back: SLA levels should reflect what your architecture actually delivers — 99.95%+ is a fair ask for transaction-critical services, but signing it without the infrastructure behind it converts a sales win into a credits machine (see our guide to service level agreements). Liability tied to "any regulatory breach" of the customer should be resisted — you can warrant your service, not their compliance. And the deal cycle is real: 6–12 weeks through procurement, risk, information security, and compliance is normal, so price the sales cost in. The full vendor-side playbook overlaps heavily with the rights buyers take in IT outsourcing and managed services agreements — in this market, you are the outsourced provider.
The perimeter question for fintechs
Before a single agreement is drafted, one question decides everything: does your product cross a regulatory perimeter? A contract cannot fix an authorisation problem — if the product needs a licence, registration, or sponsorship, that structure comes first and the contracts are built around it. These perimeters are specialist territory; the table below is a checklist of triggers, not an analysis, and each one ends the same way: get specialist regulatory advice before signing anything.
Payments
If you hold, pool, or transmit other people's money — even briefly, even as a technical intermediary — check the national payment system framework before signing anything.
South Africa's payment system runs under the National Payment System Act and SARB oversight, and participation models range from direct authorisation to sponsorship arrangements through a registered bank or designated participant. Which model your flow of funds requires is a specialist question — the answer changes the entire contract stack, so get it answered before the first agreement is drafted, not after.
Lending
If your product advances credit to consumers — including BNPL-style deferred payment — check the National Credit Act before signing anything.
The NCA imposes registration requirements on credit providers above defined thresholds, and its reach into newer deferred-payment models is an evolving question. The registration categories and thresholds are specific and change; confirm your position with a credit-law specialist before launch rather than relying on a general rule.
Advice & intermediary services
If your product gives financial advice or performs intermediary services in respect of financial products, check FAIS before signing anything.
The FAIS Act requires licensing of financial services providers, and "advice" and "intermediary services" are defined more broadly than founders expect — a robo-advice feature, a comparison engine, or an embedded insurance flow can each land inside the definitions. Whether your feature set crosses the line is a licensing question for a FAIS specialist.
Deposits
If you take repayable funds from the general public — wallets, stored value, prefunded balances — check the Banks Act before signing anything.
The Banks Act prohibition on unlicensed deposit-taking is the sharpest perimeter of all, and wallet and stored-value models can drift towards it as they scale. Structuring a product to stay on the right side of it (or under an applicable exemption or sponsorship structure) is specialist regulatory work that must precede the commercial contracts.
MJ Kotze Inc drafts and negotiates the contract stack and flags perimeter questions as they arise; where a flow of funds raises an authorisation or licensing question, specialist payments, credit, or financial-services regulatory counsel is coordinated rather than guessed at. Nothing on this page is an opinion that any particular model does or does not require authorisation.
The fintech contract stack
Once the perimeter is settled, a payment-linked product needs a contract stack that ordinary SaaS never sees. The base layer is familiar; everything above it is what makes fintech contracting its own discipline.
Platform terms — the SaaS base layer
Underneath everything sits an ordinary software contract: subscription or platform T&Cs covering access, acceptable use, fees, IP, warranties, liability, and termination. Get this layer right first — every fintech-specific layer below is bolted onto it, and a weak base contract undermines the lot.
Payment-scheme and sponsor flow-downs
If your product touches card rails or the national payment system through a sponsor bank or aggregator, their scheme rules and sponsorship terms flow down into your merchant and partner agreements. These flow-downs are largely non-negotiable; the drafting job is to pass them through accurately so you are not warranting compliance you cannot control.
Data and POPIA
Transactional data is personal information — account identifiers, payment behaviour, device data. Payment chains involve deep section 21 operator chains (fintech → processor → sponsor → scheme), each link needing operator terms, and section 72 governs any leg processed offshore. Map who is responsible party and who is operator at each hop before the DPA is drafted.
Security standards — PCI DSS by contract
PCI DSS is not South African legislation; it binds you contractually, imposed down the chain by the card schemes and your acquirer or sponsor. Your contracts must impose it downstream on anyone touching cardholder data, allocate the cost of assessments, and deal with liability for a compromise traced to your side of the chain.
Liability for payment failures and fraud
When a payment fails, is duplicated, or is fraudulent, the loss lands somewhere — and the contract decides where. Allocate liability between platform, merchant, sponsor, and end user for unauthorised transactions, chargebacks, and processing errors, and cap your exposure to events you actually control. Silence here is how fintechs end up insuring the whole chain.
Reconciliation and settlement terms
Settlement timing, reconciliation obligations, error-correction windows, holdbacks, and reserve requirements are commercial terms with hard cash-flow consequences. Define when funds become the merchant's, who bears float and interest, and the mechanics for resolving reconciliation breaks before they harden into disputes.
Regulatory-change clauses
Payments regulation moves constantly. A regulatory-change clause decides who absorbs the cost when a new directive, scheme rule, or standard forces changes to the product: vendor absorbs as cost of doing business, customer pays as a change request, or a negotiated split with a termination right if compliance becomes uneconomic. Negotiate it up front — it is the clause most likely to be invoked.
Exit and portability
Regulated counterparties will demand a documented exit plan; your merchants will want their data and, in platform models, portability of their payment arrangements. Define data-return formats, transition assistance (scoped and paid), and what happens to in-flight transactions and settlement balances on termination.
For the broader sector context — who buys, how deals run, and what the firm does for fintech clients — see our fintech industry page.
Sandboxes and partnerships
Most South African fintechs reach the market through a bank rather than around one — a partnership, embedded-finance, or banking-as-a-service arrangement where the bank provides the regulated capability and the fintech provides the product. These agreements look like commercial partnerships but carry three traps that repeat deal after deal.
Pilot-to-production gates. Bank partnerships almost always start as a pilot, and the agreement frequently leaves the conversion to production vague — no defined success criteria, no decision deadline, no agreed commercial terms at scale. The fintech carries the integration cost while the bank holds a free option. Define the gate: measurable pilot criteria, a decision date, pre-agreed production pricing (or a pricing mechanism), and consequences — including cost recovery — if the bank walks away after a successful pilot.
Exclusivity traps. The exclusivity a fintech grants to land its first bank is the clause it regrets at Series A. Broad exclusivity or rights of first refusal granted at pilot stage can lock the roadmap to one institution for years, for pilot-scale revenue, and chill investment. If exclusivity is the price of the deal, narrow it by product, segment, and territory; time-limit it; and tie it to minimum revenue that actually justifies it.
IP in integrations. A bank integration produces real intellectual property — connectors, middleware, jointly specified features. South African copyright law has a sharp edge here: for computer programs, the Copyright Act treats the person who exercised control over the making of the program as its author, so a build run tightly under the bank's direction and specifications can put first ownership genuinely in dispute. Do not leave it to the default: the partnership agreement should expressly allocate ownership of integration IP, carve out the fintech's pre-existing platform and reusable components, and licence the bank what it needs rather than assigning the crown jewels.
Where a product genuinely tests the perimeter, South Africa's regulators operate structured engagement routes — including the Intergovernmental Fintech Working Group's innovation and sandbox programmes — that allow controlled, supervised testing. Whether a sandbox route fits a particular model is, again, a question for specialist regulatory counsel; the contracting consequence is that sandbox participation comes with its own conditions that flow into the commercial agreements built during the test.
Frequently asked
What do banks demand in vendor contracts before they will sign?
A predictable list driven by their own regulatory obligations: an information-security schedule (controls, certifications, penetration testing, incident-notification timelines), audit rights for the bank and access rights for its regulators, high-availability SLAs (often 99.95% or better for anything transaction-critical), a documented business-continuity and exit plan, approval rights over sub-outsourcing and hosting changes, and POPIA operator terms. Expect a vendor due-diligence questionnaire before the contract and a 6–12 week cycle through procurement, risk, and compliance. Most of it is non-negotiable in substance — the negotiation is about scope, cost allocation, and proportionality.
Do I need a licence to process payments in South Africa?
It depends entirely on what your flow of funds actually does — and this is a question to answer with a payments-regulation specialist before any contract is drafted. The national payment system framework distinguishes between participation models: holding or transmitting funds can require authorisation or a sponsorship arrangement through a registered bank or designated participant, while a pure technology layer that never touches funds may sit outside the perimeter. The categories and their boundaries are specific and evolving, so do not rely on a general guide (including this one) for the answer; we coordinate specialist regulatory counsel where the perimeter question arises.
Who is liable when fraud losses hit a payment flow?
Whoever the contracts say — there is no single statutory answer that allocates fraud losses across a payment chain. Scheme rules allocate certain chargeback and fraud liabilities between issuers and acquirers; everything below that (acquirer to aggregator, aggregator to platform, platform to merchant) is contractual. The drafting goal is to carry liability for what you control (your platform's security, your authentication layer) and pass through what you do not (compromised cards, merchant fraud, scheme-allocated losses). A fintech that signs sponsor paper without reading the liability flow-down can end up underwriting fraud across the whole chain.
What is PCI DSS and why is it in my contract?
PCI DSS is the Payment Card Industry Data Security Standard — a contractual security standard maintained by the card schemes, not South African legislation. It binds anyone storing, processing, or transmitting cardholder data because the schemes impose it on acquirers, who impose it on their merchants and service providers by contract. If your product touches cardholder data, expect your acquirer or sponsor agreement to require PCI DSS compliance at a defined level, annual validation, and liability for losses from a compromise on your side — and your own downstream contracts must impose the same on anyone you let near the data.
How does POPIA apply in payment chains?
Fully — transactional data is personal information, and payment flows create some of the deepest operator chains in commerce. A typical flow runs fintech → processor → sponsor bank → scheme, with each link processing personal information for the one above it: section 21 of POPIA requires written operator terms at each hop, section 19 security safeguards apply throughout, and section 72 governs any leg processed outside South Africa (common, since scheme infrastructure is global). The practical work is mapping who acts as responsible party and who as operator at each hop, then papering each relationship — a missing link in the middle of the chain is a compliance gap for everyone above it.
What is a regulatory-change clause and who should absorb the cost?
A clause that pre-allocates the cost and consequences of regulatory change — a new directive, a scheme-rule amendment, a revised standard — that forces changes to the product or the service. The vendor-friendly position treats customer-specific compliance as a paid change request; the customer-friendly position treats staying lawful as the vendor's cost of doing business. The sensible middle: the vendor absorbs changes that apply to its product for its customer base generally, customer-specific requirements are priced as changes, and either party can exit if a change makes the arrangement uneconomic or unlawful. In payments, this clause gets invoked — negotiate it as if it will be.
Should I accept exclusivity in a bank partnership agreement?
Very cautiously. Exclusivity and right-of-first-refusal clauses are common in bank partnership and BaaS agreements, and they are most dangerous at pilot stage: a broad exclusivity granted to land the first bank can lock your roadmap to one institution for years, for pilot-scale revenue, and make you uninvestable to competitors of that bank. If exclusivity is the price of the deal, narrow it — by product, segment, and territory — time-limit it, tie it to minimum revenue commitments that justify it, and make sure it falls away if the pilot never converts to production.
What does fintech contract drafting cost?
From R18,000 for a core platform agreement adapted for a payment-linked product. A fuller stack — platform terms plus merchant agreement, operator/DPA layer, and sponsor flow-down review — is typically quoted as a scoped project, with the price driven by how many counterparty types the product touches. Reviewing and negotiating a bank or sponsor's paper (their MSA, their outsourcing schedules) is quoted on the document set. Where a regulatory-perimeter question arises, specialist regulatory counsel is coordinated separately and scoped before any cost is incurred.
This guide is general information on fintech contracting in South Africa, not legal advice — and in particular it is not regulatory advice. Whether any product or flow of funds requires authorisation, registration, licensing, or sponsorship under the national payment system framework, the National Credit Act, the FAIS Act, or the Banks Act is a specialist question that depends on the specific facts; always obtain specialist regulatory advice on your model before contracting or launching.