Referenced payment infrastructure

The money arrives already knowing what it is for.

Referent generates the payment reference, locks it into the instruction, and reconciles every receipt against a matter, a verified payer and a complete FICA pack.

One reference, five segments
RFT·MBW·2026-0417·N04·73
Platform Firm Matter Counterparty Check

A mod-97 check digit means a transposed digit fails before the money moves, and the reference resolves to exactly one matter.

01 — The problem

Money lands in the trust account and nobody knows whose it is

A payer sends an EFT and the reference carries their name, not the matter number. The credit sits unallocated. Two days later the bookkeeper is cross-referencing bank statements against a diary.

Multiply that across a busy conveyancing practice and the trust audit becomes an investigation rather than an export. Unresolved balances turn into findings, and after prescription, unclaimed trust money is no longer the firm's to hold.

The root cause is small and stubborn: the reference is a free-text field on the payer's screen.

The reference field is not an input.
02 — How it works

Verify once, then every payment is a two-field job

01

Verify the counterparty

Identity confirmed against Home Affairs, life status checked, sanctions and PEP screening run, bank account verified against the account holder, proof of residence captured. Done once at onboarding and reusable for every payment after that.

02

Create the request

The attorney selects the counterparty, enters the matter and the amount. Referent builds the reference and binds it to that one matter.

03

The payer chooses a rail

A mandated debit order, a card payment, or an EFT with the beneficiary and reference already filled in. Banking details are never emailed and never editable.

04

Funds settle to the trust account

Settlement runs directly into the firm's Section 86 trust account through a licensed acquirer. Referent never holds client money.

05

The receipt arrives matched

Every credit lands attributed to a matter, a verified payer and the FICA pack captured at onboarding. The trust audit becomes an export.

03 — What makes it different

Built for the audit, not just the payment

The reference is generated, not typed

Five segments and a check digit, built by the platform and locked into the instruction before it leaves. The payer is never shown an editable field, so nothing arrives that has to be identified by hand.

Banking details never travel

Account details live server-side and are never sent to the payer in an email or an attachment. The most common conveyancing fraud in South Africa depends on intercepting exactly that message.

Switch-agnostic by design

Referent is not tied to one acquirer, one switch or one bank. Rails connect through a single adapter interface, so the firm gets the right rail for each payment rather than the only one on offer.

04 — White label

Your client sees your firm, not us

Referent is infrastructure. The payer is a client of the attorney, and the screen they open should say so.

The firm's name leads every payer-facing surface. Referent appears once, small, at the foot — never above the fold, never in front of a client, never competing with the practice that earned the relationship.

The same platform runs under a firm's own brand, a bank's channel, or a PSP's product, without either party explaining who we are.

Mokoena Bester Wolmarans
Payment request · Transfer duty
Erf 1182 Rivonia · R 185 000.00
Powered by Referent

See the platform

Five screens, working end to end — verification, request, payer view and reconciliation.

Open the demo