Whether TapAPI’s use of the SA Smart ID chip UID as a closed-loop customer account key requires prior authorisation under POPIA Section 57

A structured analysis of the legal question, prepared for counsel review.

1. The question

Does TapAPI’s use of the anti-collision Unique Identifier (“UID”) of a customer’s SA Smart ID chip, as the internal account key for that customer’s closed-loop TapAPI record, require prior authorisation from the Information Regulator under section 57(1)(a) of the Protection of Personal Information Act, 2013 (“POPIA”)?

2. The statutory text

Section 57(1)(a) of POPIA provides:

The responsible party must obtain prior authorisation from the Regulator prior to any processing if that responsible party plans to —

(a) process any unique identifiers of data subjects —

    (i) for a purpose other than the one for which the identifier was specifically intended at collection; and

    (ii) with the aim of linking the information together with information processed by other responsible parties.

The requirement is conjunctive: both limb (i) and limb (ii) must be satisfied before prior authorisation is triggered. If either limb fails, section 57(1)(a) does not apply.

3. Preliminary: is the chip UID a “unique identifier” of a data subject?

“Unique identifier” is defined in section 1 of POPIA as “any identifier that is assigned to a data subject and is used by a responsible party for the purposes of the operations of that responsible party and that uniquely identifies that data subject in relation to that responsible party”.

The UID is a hardware identifier of the chip. It is not, in itself, an identifier of a natural person. However, once TapAPI has linked a specific chip’s UID to a specific customer’s TapAPI record, the UID is used by TapAPI “for the purposes of the operations of that responsible party” and uniquely identifies that customer in relation to TapAPI. The Regulator’s Guidance Note on section 57 (April 2022) supports a broad reading of “unique identifier” in this context.

4. Limb (i): purpose for which the identifier was specifically intended at collection

Section 57(1)(a)(i) asks whether the processing is for “a purpose other than the one for which the identifier was specifically intended at collection.”

Two candidate readings exist:

1. Narrow / technical reading. The identifier’s original technical purpose (per ISO/IEC 14443-3) is anti-collision at the radio layer. Using it as a customer account key is a purpose other than that specific technical intent.
2. Regulator’s reading. The Regulator’s Guidance Note explains that “the purpose for which the identifier was specifically intended at collection” refers to the processing purpose the responsible party had in mind at the time of collection, not to the technical role assigned by the identifier’s designer. TapAPI collects the UID at onboarding for the specific purpose of keying the customer’s TapAPI record, and uses it for that same purpose only.

On the Regulator’s own reading, limb (i) is not satisfied: the collection purpose and the processing purpose are identical.

On the narrow / technical reading, limb (i) may be satisfied. However, even if limb (i) is satisfied, limb (ii) must also be satisfied before section 57(1)(a) is triggered.

5. Limb (ii): linking with information processed by other responsible parties

Section 57(1)(a)(ii) asks whether the processing is “with the aim of linking the information together with information processed by other responsible parties.”

This is the decisive limb, and TapAPI’s architecture is designed to make it fail cleanly.

5.1 The UID is not shared with vendors

When a customer transacts at a TapAPI vendor, the vendor’s device transmits the UID to TapAPI for account lookup. The vendor’s device receives back only the customer’s first name, the transaction amount, and (after PIN verification) the customer’s photograph for visual confirmation. The UID is never returned to the vendor’s device. The vendor cannot record the UID for their own purposes, cannot correlate customers across sessions except by their alias or first name (both weak identifiers), and cannot combine the UID with any other dataset the vendor may hold.

5.2 The UID is not shared with Netcash

Netcash (Pty) Ltd holds customer funds in a segregated sub-account (52656316239) administered for TapAPI’s benefit. Netcash’s records identify TapAPI as the counter-party in respect of that sub-account, not individual customers. Individual TapAPI customers are indexed by internal wallet reference only. The chip UID is not transmitted to Netcash, nor stored in any Netcash-facing dataset.

5.3 The UID is not shared with Umbai or any VAS partner

Umbai delivers value-added services (airtime, data, electricity, vouchers) on TapAPI’s instruction. Umbai’s records identify TapAPI as the ordering party and receive only the target destination for the VAS product (e.g. an MSISDN for airtime top-up). Individual customer UIDs are never disclosed to Umbai.

5.4 The UID is not published or exposed via any API

The customer’s UID is stored only in TapAPI’s internal database. It is not accessible via any public API. It is not exposed on any external endpoint. It does not appear in any URL, in any exported document, in any statement, in any receipt, or in any customer-facing UI.

5.5 The UID is not disclosed to any regulator except under lawful compulsion

TapAPI would disclose customer UIDs to a regulator only on lawful order (subpoena, warrant, section 205 direction of the Criminal Procedure Act, or equivalent). Disclosure under lawful compulsion is not “processing with the aim of linking” within the meaning of section 57(1)(a)(ii); the aim is compliance with the law, not linkage.

6. Conclusion

Section 57(1)(a) requires both limbs (i) and (ii) to be satisfied before prior authorisation is triggered. Because limb (ii) is not satisfied on TapAPI’s architecture, prior authorisation from the Information Regulator under section 57(1)(a) is not required.

This conclusion depends on architectural controls that keep the UID inside TapAPI. Those controls are set out in section 7 below and are architectural constraints of the platform, not discretionary policy.

7. Architectural controls that support the conclusion

The conclusion in section 6 depends on the UID never leaving TapAPI. The following architectural controls make that promise verifiable:

8. Steps TapAPI has taken to seek external validation of this position

1. This analysis is published openly at https://tapapi.co.za/legal/section-57-analysis.php.
2. A notification of this position, together with a copy of this analysis, will be provided to the Information Regulator as a courtesy under cover of a separate letter.
3. The technical facts on which this analysis depends are separately documented in the Technical Brief (available on request).
4. The broader legal position on TapAPI’s identity verification and authentication process is set out in the Regulatory Position paper at /legal/regulatory-position.php.

9. What would trigger a reassessment

The conclusion in section 6 would need to be revisited if any of the following became true:

• TapAPI began transmitting the UID to a vendor, a payment processor, a VAS partner, or any other third party as an identifier;
• TapAPI began publishing the UID or exposing it via any external interface;
• TapAPI began combining its records with those of another responsible party using the UID as a join key;
• The Information Regulator issued guidance or a directive that changes the interpretation of section 57 in a manner adverse to this analysis;
• A court decision changed the interpretation of section 57 in a manner adverse to this analysis.

None of these are contemplated by TapAPI’s current architecture or roadmap.