It exists because operational systems were not designed for the evaluation stage. In the absence of an operational definition for pre-commitment interaction, institutions treat it conservatively, as though commitment has already occurred. The consequence is compliance effort expended on individuals who will never become customers. That effort is structural and recurring.

No. The question RETERA™ addresses, when does institutional responsibility begin, is a governance and compliance matter. The decision originates in risk and compliance, is approved at board level, and budget comes from regulatory risk, compliance efficiency, and client acquisition, not technology spend.

No. Compliance responsibility never leaves the institution. RETERA™ controls when that responsibility lawfully begins. After commitment, all regulatory obligations apply in full and remain entirely with the institution.

Boards carry ultimate accountability for regulatory exposure. The current exposure is structural: institutions hold personal information from individuals who evaluated and did not proceed, with no clear lawful basis for retention. RETERA™ eliminates that exposure category. The board can demonstrate, not merely assert, that pre-commitment interaction was proportionate, transparent, and consistent with existing law.

TCF Outcome 1 requires that customers are confident they are dealing with firms where fair treatment is central to institutional culture. RETERA™ enables institutions to demonstrate, with an auditable record, that pre-commitment interaction was transparent, proportionate, and non-misleading.

POPIA Section 11(1) grounds are exhaustive. For pre-commitment data from non-converting individuals, none applies cleanly: no consent for speculative retention, no contractual necessity where no contract exists, and legitimate interest does not survive proportionality review for data held from someone who chose a competitor. Section 13 purpose limitation further requires that information only be retained for its defined collection purpose, which is exhausted once evaluation concludes without commitment.

FICA Sections 21 and 21A require CDD when establishing a business relationship. The obligation attaches at that point, not at first interaction. RETERA™ operationalises what FICA already says about when that point occurs. CDD obligations apply from commitment forward, as the law intends.

Zero-party data, information the individual has voluntarily and proactively shared, with full awareness, for the specific stated purpose of evaluation. This is the most defensible category of data handling under POPIA. For non-converters, no institutional record exists after evaluation concludes, there is nothing to retain, delete, or defend.

The IFWG has formally endorsed the position that personal information stored by financial institutions belongs to the customer, and has stated that a mandatory open finance regime is the most appropriate approach for South Africa. RETERA™'s zero-party data architecture is architecturally positioned for the open finance environment the IFWG is working to establish. When the mandatory regime arrives, GRC functions that have approved RETERA™ will not be navigating that requirement as a new challenge. It will already be built into the institution's operational architecture.

TCF Outcome 1 requires that consumers are confident they are dealing with firms where fair treatment is central to institutional culture. RETERA™ records what explanations were shown, when key disclosures occurred, and when commitment was acknowledged. This provides evidence of fair, informed, and non-misleading process for regulatory review.

Under RETERA™, no personal information from non-converting prospects enters the institution's environment. The Joint Standard compliance overhead therefore attaches only to committed customers. The Control and Assurance Brief sets out the classification argument for JS1/2024 outsourcing in full.

RETERA™ does not replace, compete with, or duplicate consent and preference management systems. Those systems are designed for customers, people who have already committed. RETERA™ manages the period before that stage. At commitment, RETERA™ hands off to the institution's existing systems, which engage exactly as they do today. Institutions that have built data classification, retention, and destruction programmes under POPIA will find that RETERA™ completes the architecture, adding the pre-commitment boundary that those programmes were never designed to address.

No institutional record exists for that individual. Because RETERA™ handles only zero-party, view-only access during evaluation, no data was retained by the institution. The pre-commitment interaction concludes cleanly.

Each institution operates entirely independently. There is no shared institutional network. Information reviewed by an institution that is not selected cannot be retained, because nothing was retained in the first place.

DocuSign records that parties signed a document. A CRM records a workflow stage. Neither records the specific legal moment at which regulatory responsibility under POPIA and FICA formally attaches in a form capable of surviving supervisory review. RETERA™ records the obligation state. The distinction is the point.

No. RETERA™ does not approve, reject, or recommend decisions. All decisions remain solely with the institution.

No. Information becomes visible to an institution only when deliberately provided by the individual during an interaction they initiate. RETERA™ does not grant automatic access to personal records.

RETERA™'s cost is distributed across the lines the institution already holds: regulatory risk, compliance efficiency, and client acquisition. Budget owners are risk, compliance, and the CFO function.

As governance infrastructure, not a software licence. It sits across risk avoidance, compliance efficiency, and client acquisition budgets.

RETERA™ should be understood as an operational coordination boundary rather than a replacement operational system or conventional software vendor. It does not perform institutional functions on behalf of the organisation, does not hold institutional data, and does not create a dependency on its continued operation for existing regulatory obligations. The correct classification is governance infrastructure.

RETERA™ repositions compliance processes to apply only where a relationship actually forms. Checks that currently run on every enquiry run only on committed customers. The cost of evaluation is cleanly separated from the cost of onboarding. That is not a reduction in compliance rigour. It is compliance applied at the point the law intends, and not before.

Client acquisition: verification and onboarding spend incurred only on customers who convert. Compliance overhead: compliance processing applied to pre-commitment interactions generates no regulatory value. Regulatory risk: RETERA™ eliminates the category of risk. Consent and preference management: your existing POPIA infrastructure governs committed customers, the population it was designed for, rather than being burdened with pre-commitment data of uncertain legal standing.

RETERA™ is priced as governance infrastructure reflecting scope and regulatory exposure, not transaction volume, data processed, or individual compliance events. Pricing detail is introduced during the structured review process under appropriate confidentiality.

It redirects an existing one. The cost of pre-commitment compliance is already being incurred. RETERA™ reallocates that spend to the point where it produces regulatory value: after commitment, on customers who convert.

Yes. Once the board has approved participation, standard vendor assessment documentation, a data processing agreement, and security posture information are available. RETERA™ is designed to achieve ISO 27001, SOC 2 Type II, ISO 27701, ISO 22301, and ISO 27017 upon build completion.

Existing onboarding, compliance, consent and preference management, and record-keeping systems are unaffected. RETERA™ sits upstream of those systems. Once commitment occurs, data flows into existing institutional systems and processes in the normal way. Nothing in the downstream process changes.

The commitment event is the moment at which an individual explicitly agrees to enter a relationship with the institution, and the institution accepts. It is observable and auditable. RETERA™ records this event: timestamp, parties, and context. Before that event, information may be reviewed as zero-party data. After that event, regulatory obligations attach and institutional systems engage.

No. RETERA™ integrates by signalling workflow state, not by storing records or replacing data pipelines. No bulk data migration, no infrastructure replacement, no ongoing data pipeline. No changes to consent and preference management platforms.

RETERA™ is designed to sit alongside existing institutional architecture, not inside it. No changes to core banking, policy, CRM, or compliance platforms are required. Integration focuses on workflow state and audit signals, not data ingestion.

No. In practice, RETERA™ reduces onboarding time. The commitment boundary enforces readiness before obligation attaches, which eliminates document chasing, reduces repeated requests, and presents information in the order it is required.

Existing customer relationships continue unaffected. No data is lost. RETERA™ does not hold institutional customer records. Institutions can revert to existing processes. RETERA™ is an enabling control, not a single point of regulatory dependency.

RETERA™ is designed to achieve the following certifications upon build completion, these are not certifications currently held: ISO 27001; SOC 2 Type II; ISO 27701, directly relevant to POPIA and zero-party data architecture; ISO 22301; ISO 27017. POPIA and GDPR compliance are by architectural design.

Yes. Once the board has approved participation, standard vendor assessment documentation, a DPA, and security posture information are available to support CIO and operations review. Implementation documentation follows the governance decision.

RETERA™ does not hold institutional customer records and does not function as a material operational system triggering outsourcing classification under Joint Standard JS1/2024. The integration surface is narrow: workflow state and audit signals only. The Control and Assurance Brief sets out the classification argument in full.