Lawfulness of TapAPI’s identity verification, chip UID use, and PIN authentication

A structured analysis of the legal basis for TapAPI’s closed-loop customer onboarding and transaction authentication under South African law.

1. Purpose

This paper sets out TAPAPI (Pty) Ltd’s (“TapAPI”) position on the lawfulness of the following aspects of its closed-loop record-keeping service:

1. The use of the customer’s South African Smart Identity Card (“Smart ID”) for both onboarding and for identifying the customer at the point of transaction;
2. The use of the chip’s anti-collision identifier (the NFC UID) as an internal customer account key;
3. The use of a customer-chosen PIN as the authorising factor for every transaction; and
4. The distinct fact that TapAPI does not, and does not need to, read protected data groups on the Smart ID chip or perform any government-authenticated verification.

The paper is intended to inform regulators, prospective vendors, customers, and researchers about TapAPI’s approach. It also forms part of the record TapAPI maintains in connection with its filing for registration as a closed-loop payment system operator with the South African Reserve Bank (“SARB”) under paragraph 42.3 of the draft Directive on Payment Activities published on 14 November 2025.

2. Executive summary

TapAPI takes the position that its identity verification and authentication process is lawful under South African law because:

1. It reads only publicly visible and publicly readable elements of the Smart ID (printed information on the face of the card, and the PDF417 barcode printed on the reverse).
2. It reads the chip’s anti-collision UID, which is broadcast in the clear by every NFC-A compliant chip during the ISO/IEC 14443-3 collision-resolution phase, and which contains no personal information.
3. It does not attempt to read, decrypt, or authenticate any protected data group on the chip, does not perform PACE (Password Authenticated Connection Establishment), BAC (Basic Access Control), or EAC (Extended Access Control), and does not use secure messaging.
4. The customer consents, in a POPIA-compliant manner, to each item of processing at the point of onboarding and at each transaction.
5. Every transaction requires the customer’s PIN, which is a knowledge factor known only to the customer.

The combination is functionally equivalent to established, uncontroversial commercial practice: visual document check + barcode scan + hardware token + knowledge factor. It is materially and legally distinct from a Home Affairs-style identity verification, and does not require Department of Home Affairs (“DHA”) authorisation.

3. What TapAPI reads and stores — and what it does not

3.1 Surface elements

The printed information on both faces of the card is intended, by design, to be read by any human or optical device. Nothing in South African law restricts the reading of what is printed on the outside of a Smart ID by an entity that has been shown the card by its lawful holder with consent.

3.2 PDF417 barcode

The PDF417 two-dimensional barcode on the reverse of the Smart ID is a public, unencrypted, standardised barcode format. It is designed for optical machine reading. It contains substantially the same information printed on the face of the card, plus additional check fields. Its use by businesses for verification purposes is common, uncontroversial, and predates the introduction of the Smart ID in 2013.

See, in comparison, similar barcode-reading practice at pharmacies (Schedule 5 medication register), casinos (FICA Section 21), and telecommunications operators (RICA registration).

3.3 The NFC anti-collision UID

The UID is a hardware-level identifier that all NFC-A cards broadcast in the initial collision-resolution phase of ISO/IEC 14443-3 before any secure channel is established. It is broadcast in the clear. Reading it requires no authentication, no cryptographic material, and no cooperation from the card’s issuer. It is functionally analogous to the MAC address on a network interface: a hardware token useful for identification within a single closed system, but not proof of identity to third parties.

TapAPI treats the UID as an internal account identification key. It is used to look up the customer’s TapAPI record when the card is presented to a vendor. It is not published, not disclosed to third parties, and not used as evidence of the customer’s legal identity in any regulatory context.

Reading a chip’s UID is not restricted by the Identification Act 68 of 1997, the Identification Amendment Act 8 of 2000, the National Identification Regulations, or any DHA directive that has been made public. Chapter 3 of the ICAO Doc 9303 series (which the SA Smart ID follows) explicitly documents the UID as freely broadcast pre-authentication.

3.4 The customer’s PIN

The PIN is chosen by the customer during onboarding, stored only as an Argon2id hash with a per-record salt, and is never disclosed to the vendor, to any other customer, or to TapAPI staff. Every debit transaction requires the correct PIN. The PIN is a knowledge factor in a standard two-factor authentication combination (possession of the card + knowledge of the PIN).

4. Why this is materially different from full chip verification

A meaningful legal and technical distinction exists between:

• Full chip verification — reading protected data groups (DG1–DG16), performing PACE/BAC/EAC handshakes with the chip, verifying digital signatures against the DHA’s Certificate Signing Root, and treating the resulting cryptographically-attested data as proof of legal identity. This process typically requires DHA-issued Terminal Authentication certificates and, in practice, a formal relationship with the DHA.
• TapAPI’s process — visually inspecting the card, optically reading the PDF417 barcode, capturing the anti-collision UID for internal indexing, and combining that with a customer-chosen PIN and a live selfie. None of these steps require or purport to invoke DHA-authenticated verification.

The customer, in TapAPI’s process, is not being “verified against the DHA”. The customer is being identified using the card they hold, in combination with something they know (the PIN) and something they are (the live selfie). The resulting account within TapAPI is not represented to any third party as a government-verified identity; it is represented as a TapAPI account that was opened by a person who at that moment held the card, knew the PIN, and passed a liveness check.

5. Legal basis for each element

5.1 The identity verification act itself

South African law does not require a private business that opens a customer account to verify that customer’s identity against any government system. Where such verification is required, it is typically imposed by sector-specific legislation:

• The Financial Intelligence Centre Act, 2001 (“FICA”) imposes customer due diligence obligations on accountable institutions listed in Schedule 1 of the Act. TapAPI is not currently an accountable institution; its closed-loop record-keeping activity is not a listed activity.
• The Banks Act, 1990 imposes verification obligations on banks and deposit-taking institutions. TapAPI is not a bank and does not accept deposits.
• The Regulation of Interception of Communications and Provision of Communication-Related Information Act, 2002 (“RICA”) imposes verification obligations on telecommunication service providers. TapAPI is not a telecommunications provider.

Because TapAPI is not caught by these regimes, the standard of identity verification it applies is a matter of its own risk appetite and contractual arrangements, subject to the general obligations of the Consumer Protection Act, 2008 and POPIA.

5.2 Consent under POPIA

The Protection of Personal Information Act, 2013 (“POPIA”) governs the processing of personal information. TapAPI relies on the customer’s consent (POPIA section 11(1)(a)), given in the TapAPI app during onboarding, for each item of processing:

• Reading and storing the surface elements of the card;
• Reading and storing the PDF417 barcode contents;
• Reading and storing the anti-collision UID;
• Capturing and processing a live selfie for liveness confirmation;
• Storing an Argon2id hash of the customer’s chosen PIN.

The consent is specific, informed, and voluntary. The customer may withdraw consent and close their TapAPI record at any time. The lawful basis is documented in TapAPI’s Consumer Consent document, published at /legal/consumer-consent.php.

5.3 The PDF417 barcode

The PDF417 barcode on the reverse of the Smart ID is intended to be optically read. Its contents mirror the printed information on the face of the card. No South African statute or regulation known to TapAPI restricts the reading of the PDF417 barcode by a private business with the consent of the cardholder.

5.4 The NFC UID

The UID is a hardware identifier broadcast in the clear before any authentication takes place. Reading it does not compromise any protected data on the chip, does not require any cryptographic material, and cannot be used to authenticate the card as genuine. Its function within TapAPI is limited to indexing the customer’s TapAPI record; it is not used or represented as evidence of the customer’s legal identity.

By analogy, the practice of reading the UID of an NFC transport card (e.g. Gautrain gold card, MyCiTi card), a hotel access card, or an office building access card is universal and uncontroversial. The Smart ID chip is technically similar; the legal analysis of reading its UID is the same.

5.5 The PIN

The PIN is a customer secret chosen at onboarding. TapAPI does not know it, does not store it, and cannot recover it. Only an Argon2id hash of the PIN is retained, with a per-record salt. The vendor never sees the PIN. Every debit transaction requires the correct PIN to be entered by the customer on the vendor’s device, using a randomised keypad layout to defeat shoulder-surfing.

6. The transaction process — sequenced to protect the customer

Every debit transaction at a TapAPI vendor follows a fixed sequence designed to (i) protect the customer’s personal information from disclosure without authentication, and (ii) provide the vendor with a final visual check before the transaction is committed:

1. The customer presents the card. The vendor’s device reads the anti-collision UID.
2. TapAPI looks up the account. The device receives only the customer’s first name and the amount field, with the photo withheld.
3. The customer enters the PIN. The keypad on the vendor’s device is a randomised layout; the PIN is entered by the customer, not the vendor.
4. Only if the PIN is correct, the customer’s photograph is released to the vendor’s device. The photograph appears on-screen for the vendor’s visual comparison against the person standing at the till.
5. The vendor confirms the visual match. This is a positive action by the vendor — a tap of a confirmation button. Without this positive confirmation, the transaction is not committed.
6. The transaction is committed. TapAPI records the transaction on the closed-loop ledger; the customer’s photo is cleared from the vendor’s device.

This sequence has two properties worth explicit note:

• The customer’s photograph is only disclosed to the vendor after the customer has successfully authenticated with a PIN. A vendor cannot fish for the customer’s photograph by presenting a card without the customer’s cooperation.
• The final commit requires positive vendor action. This defends against automated fraud and against a customer being charged for a transaction they did not authorise.

7. Comparison to established, uncontroversial commercial practice

Every element of TapAPI’s process has an established, uncontroversial commercial analogue in South Africa:

• Visual document inspection — performed daily at every bank branch, insurance office, cellphone shop, motor vehicle dealer, letting agent, and post office in the country.
• PDF417 barcode reading — used by police at roadblocks (with the DriverCheck-style handheld devices), by driving licence renewal centres, by security firms at gated estates, and by many private employers during pre-employment screening.
• NFC UID reading — used by every access control system in every office building, every hotel key card system, and every public transport tap card.
• PIN authentication — the entire card payment industry.
• Live selfie + liveness — used by every major bank’s onboarding app, by SARS eFiling for identity uplift, and by all licensed digital identity providers.

What is not established practice, and what TapAPI does not do, is reading the protected chip data of the Smart ID. That practice is regulated for good reasons and requires a formal relationship with the DHA. TapAPI has no need to do this and has consciously chosen not to.

8. Regulatory positioning

SARB — closed-loop payment system operator. TapAPI has filed the closed-loop registration under paragraph 42.3 of the draft Directive on Payment Activities. See PAIA Manual section 5.7 for further detail.

Information Regulator — POPIA. TapAPI’s Information Officer is registered with the Information Regulator under registration number 2026-061457.

FIC — FICA. TapAPI is not currently an accountable institution. Should TapAPI in future fall within FICA scope (whether by activity, by threshold, or by regulatory amendment), it will register accordingly and adopt the customer due diligence measures required. The current onboarding process already collects information sufficient to meet FICA simplified due diligence thresholds should this become required.

DHA. TapAPI does not read protected chip data and does not require DHA authorisation. Should TapAPI in future wish to add chip-authenticated verification, it will apply for the appropriate authorisation before doing so.

NCR — National Credit Act. TapAPI does not extend credit. TapAPI credit is prepaid purchase credit; it is not a loan, an advance, or a credit facility as defined in the National Credit Act, 2005.

FSCA — Financial Advisory and Intermediary Services. TapAPI does not render a financial service as defined in the Financial Advisory and Intermediary Services Act, 2002.

9. Conclusion

TAPAPI (Pty) Ltd’s customer identification and authentication process is:

• Built exclusively on public-facing elements of the Smart ID and a customer-chosen PIN;
• Distinct in law and in fact from full chip verification;
• Consented to by the customer under POPIA;
• Built to protect the customer’s personal information (photograph disclosed only post-authentication);
• Protected by a positive vendor commit step at the end of every transaction;
• Comparable to established, uncontroversial commercial practice in every element.

TapAPI takes the position that this approach is lawful under the current South African statutory framework. TapAPI welcomes engagement from the DHA, SARB, the Information Regulator, the FIC, or any other regulator that wishes to discuss the position. Correspondence should be directed to help@tapapi.co.za.