Multi-sided platform law in South Africa: why governance architecture comes first

The most expensive mistake in multi-sided platform law isn’’ drafting the wrong agreement. It’s drafting agreements in the wrong order.

Every week, legal teams building coalition loyalty platforms produce careful, well-drafted bilateral contracts—partnership agreements, data processing agreements, service level agreements—only to discover, usually at the point of onboarding the third or fourth major partner, that nothing in the contractual stack actually governs who has the authority to change the rules. The governance architecture, if it exists at all, was assembled after the commercial relationships were already in place. By then, it’s too late. The party that signed first set the terms, and those terms almost always favour the operator.

This is not a drafting problem, rather it’s a sequencing problem. And it is the entry point into everything that makes multi-sided platforms (MSPs) legally distinct from the commercial structures that most practitioners are trained to advise on.

Why standard legal frameworks fail MSPs

Commercial law is built on a bilateral assumption: one party offers, another accepts, obligations flow between them. This assumption is so embedded in how lawyers are trained to think—in contract, in tort, in regulation—that it takes conscious effort to set it aside.

An MSP violates it structurally. When a banking partner contributes customer data to a coalition platform, it is not simply entering a data-sharing arrangement with the operator. It is entering a data environment shaped by every other brand in the coalition—a telco, an insurer, a grocery retailer—none of whom it has a direct contractual relationship with, but whose data contributions will combine with its own to create analytical outputs that no party could generate alone. When a consumer earns rewards with one partner and redeems them at another, the legal obligations arising from that journey span at least three entities, potentially several more, and involve regulatory frameworks (like data protection, consumer protection, competition law, payment services regulation) that are each designed for simpler structures.

Legal advice that treats each bilateral relationship in isolation will miss the systemic risks. You can have fourteen perfectly drafted bilateral agreements and still have a platform that is ungovernable, legally exposed, and structurally fragile. What the platform needs, before any of those agreements are negotiated, is a governance architecture that determines how decisions get made when the interests of different participants diverge.

The governance choice that shapes everything else

Before any agreement is drafted, there is a prior question: what governance model has the platform adopted, and has that choice been made deliberately?

MSP governance sits on a spectrum. At one end, the fully centralised model: the operator sets all rules unilaterally, controls the currency and data architecture, and partners participate on terms the operator dictates. At the other end, the federated model: the operator runs the infrastructure, but partners retain meaningful sovereignty over their own earn rules and customer relationships, and material platform changes require partner council approval.

Most South African coalition platforms launch with a centralised model, because it’s operationally convenient and partners accept it during the honeymoon period of early coalition formation. The legal problems begin when the platform scales.

A centralised operator that sets rules affecting the commercial conduct of multiple independent market participants — a bank, a telco, an insurer, a retailer — is structurally exposed to characterisation as a dominant firm under the Competition Act 89 of 1998. The Competition Commission has not yet issued platform-specific guidance in South Africa, but the analytical framework is clear: arrangements that allow one party to dictate terms to a coalition of competitors, and that create barriers to exit through accumulated consumer balances and deep API integration, are the architecture most likely to attract scrutiny as the market matures.

Under POPIA, the centralised model makes the operator the sole Responsible Party for everything: a clean legal line, but one that concentrates regulatory risk dangerously. The federated alternative requires each partner to retain Responsible Party status for the data they originate, which means characterising every partner-operator data relationship as either a joint controller arrangement or an operator relationship, with explicit documentation of each. Neither option is simple. But the alternative—pretending the question doesn’t arise—is worse.

The operator that defers this governance design until after launch is not being practical; it’s deferring a liability.

Three legal questions that are harder than they look

Who controls the combined data?

Each Partner Brand collects customer data through its own first-party relationship and is the Responsible Party for that data. The moment that data is contributed to the platform and combined with data from other partners to build a unified behavioural profile, a new question arises: who controls that combined asset, and under what legal basis?

The answer is rarely addressed adequately in bilateral agreements. Most platform data clauses default to language about “data sharing” that says nothing useful about joint controllership: the arrangement required under POPIA when two or more parties collectively determine the purposes and means of processing. Where the operator independently determines those purposes, it’s the Responsible Party for the combined data and bears the regulatory risk. Where partners collectively determine them, a co-Responsible Party arrangement is required, with explicit allocation of transparency obligations, data subject rights workflows, and breach notification responsibilities between all parties.

Most platform agreements drafted to date resolve this question by ignoring it. That’s not a position that will survive an Information Regulator investigation.

What is the lawful basis for processing data before the consumer knows the platform exists?

Sophisticated platforms increasingly operate a pre-provisioning layer: partner customer data is ingested, identity resolution is performed across the coalition dataset, behavioural profiles are created, and machine learning segmentation models are run. All before the consumer has downloaded the app, consented to anything, or been told that a platform exists.

The lawful basis for this processing under POPIA section 11(1)(f) is legitimate interests: the platform operator’s commercial interest in building a personalised first-experience for the consumer, weighed against the consumer’s reasonable expectations given their relationship with the partner that shared their data. That assessment must be documented genuinely before processing begins, not drafted as a post-hoc justification. It must be reviewed as the scope of pre-processing expands. And it cannot extend to special personal information—health data, financial vulnerability indicators, biometric data—which requires explicit consent regardless of commercial framing.

The additional complication: where the segmentation layer assigns consumers to named demographic profiles (“young professional”, “retired”) before they have any relationship with the platform, and those profiles then determine the offers and rewards they encounter from their first interaction, the processing may constitute automated decision-making under POPIA’s non-discrimination provisions. Describing it as “personalisation” doesn’t resolve the legal question. The substance of the processing determines its characterisation.

Is the rewards currency a regulated payment instrument?

This is the question that most coalition platforms prefer not to ask until they have to. A loyalty currency denominated at one-to-one par with legal tender, stored in consumer accounts, and redeemable across a wide network of unrelated merchants—a bank, a fuel retailer, a grocery chain is not obviously distinguishable from a stored-value facility under the National Payment System Act. The South African Reserve Bank’s assessment is based on economic substance, not commercial label. Calling the unit a clever name rather than a “rand” settles nothing.

The regulatory perimeter question is triggered by design features, not by scale. The relevant features are par-value denomination, consumer account infrastructure, breadth of merchant acceptance, and transferability. A platform that incorporates all four without seeking a formal regulatory opinion from the SARB’s National Payment System Department before activating broad merchant redemption is not in a position to argue good faith if the Reserve Bank later determines a licence was required. That opinion should be obtained before launch, not after the programme has 20 million enrolled members.

The CSI problem: structural, not behavioural

The competition law risk in data pooling is structural. It does not require any party to act with anticompetitive intent. It arises from the architecture itself.

When a banking partner, an insurance partner, a telco, and a grocery retailer contribute behavioural data to a shared platform, the combined dataset contains information from which an analyst can infer each partner’s pricing strategy, customer acquisition costs, retention patterns, and forward commercial intentions. Even where the platform operator never shares raw partner data between partners—and it should not—the aggregated insights derived from that combined data may be sufficiently granular to constitute competitively sensitive information (CSI) exchange between competitors under the Competition Act.

A contractual prohibition on CSI sharing that sits on top of a technical architecture that permits it is not a legal defence. It’s evidence that the risk was identified and not adequately addressed. Structural safeguards, such as data clean-room architecture, independent data trustee arrangements, explicit CSI prohibition schedules with minimum aggregation thresholds, are most effective when built into the platform before it launches. They become significantly more expensive to retrofit after partners are integrated.

The independence problem nobody wants to talk about

A recurring challenge in South African coalition platforms is the structural independence of the managing entity. Where the managing entity is a wholly-owned subsidiary of a group of companies that is simultaneously one of the coalition’s largest partners—contributing products alongside external brands—the neutrality the managing entity is supposed to embody is structurally compromised by design.

This conflict manifests in specific, justiciable ways: earn rule configuration that advantages the parent group’s products; data access rights that give the parent group preferential analytical insight into partner customer behaviour; platform upgrade decisions made in the parent group’s commercial interest rather than the coalition’s. Each of these is a potential claim by an external partner. Each is more likely, not less, as the coalition grows and external partners come to have significant market power of their own.

The governance response is not to restructure the ownership. Instead, one has to build structural independence into the managing entity through independent directors, formal conflict-of-interest protocols with recusal obligations, and contractual commitments to external partners that platform decisions will be made on arms-length grounds. Those commitments need to be enforceable. An aspiration is not a governance architecture.

The three things practitioners keep getting wrong

Sequence. The constitutional governance architecture—the governance charter, the partner council structure, the reserved matter thresholds—must be agreed before the operational agreements are signed. Not drafted in parallel. Not finalised after. Agreed. Platforms that reverse this sequence lock themselves into commercial commitments that no subsequent governance document can easily override, because the party with the most leverage has already used it.

Scope. An adviser retained to draft a partnership agreement, or a data processing agreement, or a consumer terms document, will produce inadequate work if they treat that brief in isolation from the platform’s governance model, data architecture, and regulatory positioning. The systemic risks do not care about the boundary of the instruction.

Timing. The Information Regulator is increasingly active on enforcement. The FSCA is developing frameworks for data-intensive financial services platforms under Joint Standard 1 of 2023. The Competition Commission is watching data markets. Advising clients to defer governance and compliance work until the platform is established is not a conservative posture; it is an exposure. The moment to fix the governance architecture is before the platform has the scale that makes fixing it commercially and legally complicated.

How ITLawCo can help

ITLawCo advises on the full lifecycle of multi-sided platform design, governance, and regulatory compliance: from pre-launch architecture through to live platform assurance and regulatory engagement.

To discuss how ITLawCo can support your platform, contact us.

FAQ

ITLawCo provides specialist legal advisory services in technology, data protection, and platform governance. This article is for informational purposes only and does not constitute legal advice. All analysis reflects the regulatory position as at March 2026. For advice on a specific matter, please contact us.