About RainFin

The accountable institution, the products in scope, and the legal posture of the firm.

Who we are

RainFin (Pty) Ltd is an authorised financial services provider (Category I) and a registered crypto asset service provider under the FSCA's CASP licensing regime (sub-category 1.27 under FSCA FAIS Notice 90 of 2022 and the declaration of crypto assets as a financial product under General Notice 1350 of 2022). RainFin is registered with the Financial Intelligence Centre as an accountable institution in two capacities — Item 12 of Schedule 1 (financial services provider) and Item 22 of Schedule 1 (crypto asset service provider). The FIC registration number is AI/131104/00006.

RainFin operates from South Africa and serves South African residents.

Products in scope of this programme

• The RainFin Wallet — a retail wallet enabling South African residents to onboard onto, hold, transfer and convert crypto assets and stable money.
• The AVBOB Wallet — offered through RainFin under a juristic representative arrangement with AVBOB, enabling AVBOB customers to access a regulated digital wallet.
• Stable money and yield-bearing balances — including ZAR-referenced stable money products whose yield is referenced to the Ninety One Money Market rate.
• Crypto asset trade and transfer — the on-ramp and off-ramp between fiat and crypto, peer-to-peer transfer, and counterparty CASP transfer.
• Tokenisation of real-world assets — the design and issuance of tokens representing real-world financial or commercial value, for institutional and qualifying-retail customers.

Registered information

The address of the registered office and the contact details for the Compliance Officer are recorded with the FIC and kept current under section 43B(4) of the FIC Act. Any change to registered information is filed within five business days; changes to the Compliance Officer are filed at least five days before the effective date where possible.

Regulatory framework

The statutes, directives and standards that this programme implements.

Roles and accountability

Who does what at RainFin — the named individuals and the duties they own.

Notification obligations

Section 43B(4) of the FIC Act requires the accountable institution to notify the FIC of any change to its information within 90 days. Material changes to the Compliance Officer are notified at least five business days before the effective date where possible. The current notification clock began on 5 May 2026 (resignation of Gary Greyvenstein) and runs to 3 August 2026.

The compliance function

The duties of the Compliance Officer and the wider compliance team.

The Compliance Officer is responsible for:

• Developing, maintaining and reviewing this programme.
• Ensuring all employees are trained in line with the Employees section.
• Performing or supervising customer due diligence, including client risk rating and source-of-funds verification.
• Effective implementation and monitoring of CDD procedures.
• The filing of CTR, STR, TPR and IFTR with the FIC via goAML.
• The handling of section 27, section 32 and section 34 requests and directives.
• Liaison with the FIC, the FSCA and other regulators on accountable-institution matters.
• Maintenance of the firm's registration with the FIC including the section 43B(4) updates.
• Reporting to senior management and the Board on a regular basis on the firm's compliance posture.

Conflicts of interest

How RainFin manages conflicts arising from the Compliance Officer's dual employment.

The Compliance Officer is part-time employed by RainFin and part-time employed by CAEP Partners. This creates a conflict on matters where CAEP provides services to RainFin. The conflict is managed as follows:

1. Service-provider matters referred to the KI. Any matter that concerns CAEP's performance as a service provider to RainFin is referred by the Compliance Officer to the Key Individual for decision. The Compliance Officer does not adjudicate CAEP's own performance.
2. Contract negotiations on the KI side. Contract negotiations between RainFin and CAEP are conducted on the RainFin side by the Key Individual, not by the Compliance Officer.
3. Board awareness. The Board is informed of the dual engagement and of any specific matter that engages the conflict at the next scheduled meeting.
4. Documented record. The conflict-management record is retained on the compliance file. Each instance is logged with the date, the matter, the decision-maker and the outcome.

Other conflicts

Any other conflict of interest affecting an employee — financial, familial, prior employment — is disclosed by the employee to the Compliance Officer on appointment and on every material change. The Compliance Officer maintains the conflicts register.

Escalation

When matters move from the Compliance Officer to the Key Individual, to the Board, or to external counsel.

The escalation rule

The Compliance Officer handles every accountable-institution matter that arises in the ordinary course. The Key Individual is brought in for matters that cross a material threshold. The Board is informed at the next scheduled meeting and immediately for any event that meets the incident-escalation criteria. External counsel is engaged on any matter that could become an enforcement action.

Material thresholds that bring in the KI

• A confirmed sanctions match (true positive).
• A section 27, 32 or 34 directive from the FIC.
• Enforcement engagement by the FSCA, FIC, SARB or any other regulator.
• A customer with assets above R1 million.
• A media or political event touching the business.
• A product-perimeter question the Compliance Officer flags as material.
• A regulator on-site inspection notice.

When external counsel is engaged

• Any matter that could become an enforcement action.
• Any matter that involves a privilege question.
• Any matter that involves a regulator on-site inspection.
• Any product-perimeter question with material licensing or criminal-law exposure.

Programme review

How and when this programme is reviewed and updated.

The Compliance Officer reviews this programme at least annually and on every material change to the business. Material changes include:

• New product launches or material changes to existing products.
• Material vendor changes (Sumsub, Ravencall, custodian, settlement provider).
• Material regulatory change — new FIC Directive, FSCA Notice, MiCA-equivalent, etc.
• Enforcement events.
• Internal audit findings.
• Post-incident lessons.

Material amendments are approved by the Board. Minor wording corrections are approved by the Compliance Officer and noted to the Board at the next meeting. Each review is recorded in the change log.

Availability

The current version is held at this docs site. Every employee signs a declaration of receipt and understanding on first appointment and on every material amendment. The Compliance Officer notifies all employees of material changes by email. The programme is made available to the FSCA, the FIC and any other regulator on request. RainFin does not share the programme in its entirety with customers, partners or service providers, on the basis that doing so would expose the firm's control environment to circumvention.

The three KYC tiers

Every customer starts at Level 1 and steps up to a higher level when their exposure or activity reaches the threshold.

The tiers

Level 1 — Entry

Active while: lifetime combined exposure across all linked wallets is under R50,000 AND current calendar-month value in plus value out is under R50,000.

Verification steps: identity document (SA ID for South Africans; passport for non-South Africans); biometric liveness; full name, email, mobile, date of birth, country of residence; FICA self-declaration questionnaire; tax identification number where applicable; sanctions, PEP and adverse media screening at onboarding.

Step-up trigger: either threshold reaches R50,000 — step up to Level 2.

Level 2 — Enhanced

Active while: lifetime combined exposure and current calendar-month activity are both under R100,000.

Additional verification steps: proof of residential address (utility bill, bank statement, lease or official correspondence not older than three months) and a source of funds declaration.

Step-up trigger: either threshold reaches R100,000 — step up to Level 3.

Level 3 — EDD

Active while: no platform-imposed cap.

Additional verification steps: video identification interview (live agent or recorded-and-reviewed) and proof of source of funds (document evidence — salary advice, sale of asset documents, business income evidence, inheritance documents); proof of source of wealth for high-value clients.

Ongoing: continuous monitoring; quarterly file refresh; Compliance Officer review on first transaction at this tier.

Reference periods, grace and downgrade

The current-month test runs on the calendar month. The reference period resets on the first day of each calendar month at 00:00 SAST. Lifetime exposure does not reset.

Grace period. When a step-up trigger fires, the customer has seven calendar days to complete the higher-tier verification. During the grace window the wallet remains open for inbound transactions, but outbound transactions are capped at the previous tier's threshold. At day eight, outbound transactions are blocked entirely until verification is complete. The Compliance Officer can grant a hardship override; each grant is logged.

Downgrade. Customers are not automatically downgraded if their balance or activity subsequently falls. Once a control is applied, it is not removed — a tier represents the high-water mark of the customer's exposure. A formal downgrade requires Compliance Officer review with documented reasons.

Cross-wallet aggregation

Thresholds apply at user level, not wallet level. Users cannot evade tiering by opening multiple wallets.

The platform automatically identifies and links wallets belonging to the same user or entity, using:

• KYC identifiers — ID number, passport number, registration number, beneficial owner records.
• Device fingerprinting.
• IP clustering.
• Behavioural patterns.

Total deposits, total withdrawals and total lifetime exposure are aggregated across the linked wallets in real time. The aggregation runs continuously and is checked on every transaction.

Cross-wallet linking applies at all tiers and is not optional. Structuring across multiple wallets is treated as an STR scenario under section 7 reporting.

Customer identification — natural persons

How RainFin identifies and verifies natural persons at onboarding.

South African nationals

Identity is verified by comparing the customer's identity document or passport to a reliable and independent third-party data source. Sumsub performs the document authenticity check, the biometric liveness check, and the data-comparison check against South African public records.

Foreign nationals

Verification is performed against the customer's passport, with additional checks for country of issue, country of residence and visa or permit status where relevant. Enhanced source-of-funds verification applies where the customer's home jurisdiction is on a FATF or sanctions list.

Standard identification dataset

• Full legal name.
• Identity or passport number.
• Date of birth.
• Country of birth and country of residence.
• Residential address (collected at Level 2 and above).
• Contact number, email address.
• Citizenship.
• Tax identification number — mandatory from SARS CARF effective date (1 March 2027).
• Source of funds declaration.

Detailed checklist: Annexure C — Document checklists

KYB — legal persons, partnerships, trusts

Additional due diligence for non-natural customers under section 21B of the FIC Act.

Where a customer is a legal person, partnership or trust, additional due diligence applies. The purpose is to:

• Understand the nature of the customer's business.
• Identify the ownership and control structure.
• Identify the beneficial ownership — every natural person who ultimately owns or controls the customer.
• Pierce the corporate veil where required.
• Prevent misuse of the legal person for ML/TF/PF.

Required documents by entity type

See Annexure C for the full document checklists. Summary:

Beneficial ownership process: see next page.

Beneficial ownership determination

The FIC's three-step process of elimination for identifying the beneficial owner of a legal person.

A beneficial owner is the natural person who ultimately owns or exercises effective control of the customer. The determination follows the FIC's three-step process of elimination, set out in Guidance Note 7 and PCC 59.

Step 1 — Controlling ownership interest

Identify each natural person who has a controlling ownership interest in the legal person by holding 5% or more of the shares or membership interest, independently or in partnership with another person, directly or indirectly.

Step 2 — Control through other means

If no natural person can be identified through Step 1, or if there is doubt as to whether the persons with controlling ownership interests are the beneficial owners, identify the natural person who exercises control of the legal person through other means — voting rights, shareholder agreements, control of other legal persons, acting in concert.

Step 3 — Control over management

If no natural person can be identified through Steps 1 or 2, identify the natural person who exercises control over the management of the legal person — executive officer, chief financial officer, senior managing official, non-executive director, independent non-executive director, manager.

Partnerships

Every partner is identified regardless of percentage ownership (section 21B(3)(b) FICA). Every natural person authorised to act on behalf of the partnership is identified. The natural person(s) who exercise executive control of the partnership are identified. For en commandite and anonymous partnerships, the silent partner(s) are identified.

Trusts

The founder, every trustee, every named beneficiary, and any natural person authorised to act on behalf of the trust are identified. Where the trustee is itself a legal person, CDD is performed on that legal person and its beneficial owners. Where the founder is itself a legal person, CDD is performed on that legal person and its beneficial owners. Where beneficiaries are described by class rather than named, particulars of how beneficiaries are determined are obtained.

PEP, PIP and FPPO screening

Politically exposed persons, prominent influential persons, foreign prominent public officials.

Schedule 3A of the FIC Act lists the domestic and foreign positions that qualify as politically exposed persons. Schedule 3C lists the positions that qualify as prominent influential persons. RainFin uses the Act's defined terms throughout — domestic prominent influential person (DPIP), foreign prominent public official (FPPO), and the FIC Act's defined terms for PEPs.

Screening triggers

• At onboarding.
• At every tier step-up.
• On receipt of TFS list updates.
• Continuously thereafter (Sumsub and SNTNL run continuous PEP and adverse media screening).

Family members in scope

Immediate family members are within scope of the screening. In terms of FICA:

• Spouse, civil partner or life partner.
• Previous spouse, civil partner or life partner if applicable.
• Children and stepchildren and their spouse, civil partner or life partner.
• Parents.
• Sibling and step-sibling and their spouse, civil partner or life partner.

Risk treatment

Domestic PEP, DPIP, FPPO — not inherently high risk. Each relationship is assessed on its merits using the Annexure A indicators. Where the relationship is found to be high risk, the same requirements as for a foreign PEP apply. The decision is documented on the customer file and signed off by the Compliance Officer.

Sanctions screening

Continuous screening against the TFS list and other sanctions lists; treatment of true and false positives.

Lists screened against

Every customer, every beneficial owner and every person acting on behalf of a customer is screened against:

• FIC Targeted Financial Sanctions (TFS) list — the FIC-published version of the UNSC consolidated list under sections 26A, 26B and 26C of the FIC Act.
• OFAC SDN list.
• HM Treasury Office of Financial Sanctions Implementation (OFSI).
• EU Consolidated Financial Sanctions list.
• EU Most Wanted list.
• Bureau of Industry and Security list.
• US State Department Foreign Terrorist Organizations and Non-Proliferation lists.
• US DOJ wanted lists.
• Interpol's Most Wanted.
• CBI list.
• Any list published by the FIC or the South African Government under POCDATARA.

When screening happens

• At onboarding.
• On every transaction.
• On each TFS list update (and at least weekly).
• Continuously for adverse media and PEP designation through SNTNL and Sumsub.

RainFin subscribes to the FIC's TFS automated notification email to receive alerts on every update.

Possible match — false positive

Where a possible match is found and the Compliance Officer determines it is a false positive (the customer has the same name as a sanctioned person but is not the same person), the basis is documented and onboarding may continue. The investigation record is retained on the customer file.

Possible match — true positive

POCDATARA court orders

Customers are also screened against court orders made under POCDATARA and against any directive issued under section 34 of the FIC Act. Where a customer is subject to such an order or directive, the Compliance Officer freezes the relevant assets, blocks further transactions, notifies the issuing authority of the firm's possession of the assets, and follows the reporting process in section 7.

Anonymous customers and inability to conduct CDD

Hard rules where the customer cannot or will not be identified.

Where a relationship has been established and it subsequently becomes apparent that the customer is anonymous or has used a false identity, the relationship is terminated and a section 29 STR is filed. The customer is not informed of the reason for termination where to do so would constitute tipping off.

Inability to conduct CDD

Where a customer refuses to provide the information or documentation required for CDD at the relevant tier, RainFin:

• May not establish a business relationship.
• May not conclude a single transaction.
• Must terminate any existing relationship.
• Must consider filing a section 29 report.

The customer is informed of the consequences before the refusal becomes terminal, but is not informed of the reason for termination where to do so would constitute tipping off.

Customers with prior criminal convictions

A risk-based, rehabilitation-aware onboarding process — no automatic exclusion.

RainFin recognises South Africa's constitutional and policy objectives of rehabilitation and reintegration, and does not apply automatic exclusion to prospective customers solely on the basis of a historical criminal conviction. Each application is assessed on its own merits using a documented, risk-based approach.

The process

1. Disclosure and verification. The applicant provides sufficient detail to enable assessment — the nature of the offence, the date of conviction, confirmation that the sentence has been served, and confirmation that no ongoing legal restriction would prevent participation in the financial system.
2. Relevance assessment. The Compliance Officer assesses whether the offence indicates elevated exposure to financial crime, dishonesty, violence, organised crime or other ML/TF/PF risk drivers.
3. Risk rating and EDD. Where the assessed risk is high, EDD applies — deeper verification, corroboration of information, enhanced monitoring.
4. Compliance Risk Committee approval. The application is decided by the Compliance Risk Committee, not by an individual. No single employee may approve or decline.
5. High-risk watch list and ongoing monitoring. Accepted customers are included in the high-risk watch list and subject to more frequent ongoing CDD.
6. Documented record. The rationale for acceptance or decline is documented and retained on the customer file.

Where residual risk is assessed as unacceptable, the application is declined or the relationship is terminated. The decision is documented.

Unhosted wallets and anonymous crypto-asset transactions

Hard rules on transfers involving self-custodial wallets and on anonymous crypto-asset activity.

Unhosted wallets

Unhosted (self-custodial) wallets present heightened risk because there is no third-party oversight of ownership or control. RainFin does not permit inbound or outbound transfers to or from unhosted wallets unless the originator or beneficiary can be clearly identified and verified through appropriate CDD measures.

Where a transaction involving an unhosted wallet is approved, EDD applies:

• Verification of the natural person controlling the wallet.
• Confirmation of the source-of-control attestation.
• Compliance Officer sign-off.
• Enhanced ongoing monitoring of onward activity from the unhosted wallet.

Inability to verify ownership results in the transaction being declined and, where appropriate, in a section 29 report.

Anonymous crypto-asset transactions

Last live Travel Rule exchange report

Where Travel Rule data is incomplete, inconsistent or unverifiable, RainFin initiates a CDD process to obtain the missing data from the sending or receiving party, and may decline the transaction if the data cannot be obtained.

RainFin does not accept funding from privacy coins (Monero, Zcash) where the funds cannot be traced.

Approach to risk — methodology

How RainFin scores and re-scores ML/TF/PF risk.

RainFin applies a risk-based approach. We classify our exposure to money laundering, terrorist financing and proliferation financing risk by considering, in order, the inherent risk of each product and service we offer, the inherent risk of the customer base we serve, the inherent risk of the channels through which we deliver, and the inherent risk of the geographies our customers come from and transact with. We then assess the effectiveness of our controls and arrive at a residual risk.

Reference points

The business risk assessment is informed by three external assessments:

• FIC National Risk Assessment — most recently the Terrorist Financing National Risk Assessment of June 2024. South Africa's TF risk is rated high. International threats: ISIS, Al Shabaab and affiliates in neighbouring countries. Domestic threats: right-wing extremism, organised crime. South Africa is identified as a conduit country for illicit funds.
• FSCA Sectoral Risk Assessment for Financial Services Providers (April 2022) — rates Category I and IV FSPs as LOW for ML/TF/PF; CIS and Category II, IIA, III as MEDIUM.
• FIC Sectoral Risk Assessment for Crypto Asset Service Providers (March 2024) — identifies CASP-specific risks including pseudonymity, over-collateralisation patterns, asset-price volatility, and crypto-market interconnectedness.

Scoring methodology

Each factor is scored low (1), medium (2) or high (3) using the indicators in Annexure A. A customer's overall score is taken as the highest single factor score, not the average — a customer with one high-risk indicator is rated high risk regardless of the other indicators, unless the Compliance Officer documents a contrary decision with reasons. Residual risk is recorded as the customer-risk-score net of the controls applied at the customer's current KYC tier.

CDD intensity by risk level

Refresh triggers

Customer risk and CDD are refreshed at every tier step-up, on every trigger event, on receipt of a section 27, 32 or 34 directive from the FIC, on any material change in product holding, and at the scheduled ongoing review. The Compliance Officer also re-rates customers on receipt of TFS list updates, on material adverse media events, on the publication of a new National Risk Assessment, Sectoral Risk Assessment, or relevant FATF mutual evaluation finding, and where SNTNL flags a sustained behavioural anomaly.

Product and service risk

Summary risk rating per product. Detailed assessment in Annexure C.

Customer risk

The five-factor customer risk assessment.

Customer risk is assessed on five factors:

1. Geography — residence, contact addresses, transactional counterparties.
2. Customer type — natural person, legal person, partnership, trust, complexity of structure.
3. Product holding — which RainFin products the customer holds and at what tier.
4. Behaviour — consistency with declared source of funds, velocity, anomalies.
5. Channel — face-to-face, non-face-to-face, intermediary.

The factors and indicators are listed in Annexure A.

A customer's risk rating defaults to medium because the underlying CASP product is inherently medium-high. Specific indicators in Annexure A move the rating up or down. Foreign politically exposed persons and confirmed sanctions matches are extremely high risk by default; everything else is graded on the assessment.

The eight platform rules

The non-negotiable controls hard-coded into the transaction monitoring platform.

SNTNL by Ravencall ingests every fiat and crypto transaction in real time, scores it against the rule set below, and routes alerts to the appropriate decision point. The platform is the primary decision-maker; humans intervene only on triggered events.

Specific monitoring rules

Named alert rules configured in SNTNL on top of the eight platform rules.

The nine-step withdrawal lifecycle

Every withdrawal passes through nine steps. Steps 1–6 are automated; step 7 is exception-based human review.

Full operational detail in the Wallet-as-a-Service Withdrawal Policy at document number BMAWAASWPPRR001.

Four-tier approval workflow

SNTNL operates a four-tier approval workflow with SLA-based escalation:

• Analyst (Operations) — first-line review of medium-risk alerts; resolution or escalation within four business hours.
• Supervisor (Head of Operations) — second-line review of escalated medium-risk and routine high-risk alerts; resolution or escalation within one business day.
• Compliance Officer — third-line review of all high-risk alerts, sanctions matches, PEP designations, structuring patterns; decision on STR / CTR / TPR / IFTR filing.
• MLRO escalation point (Compliance Officer) — final escalation for regulatory engagement; engagement with the FIC; engagement with external counsel; Board notification.

Travel Rule

FIC Directive 9 of 2024 — originator and beneficiary information on qualifying crypto-asset transfers.

FIC Directive 9 of 2024, effective 30 April 2025, applies to every crypto-asset transfer above the threshold prescribed in the Directive. For every qualifying transfer, RainFin transmits the originator and beneficiary information required by FATF Recommendation 16 to the counterparty CASP, and validates receipt of the equivalent information for inbound transfers. The data exchange is automated through SNTNL's Travel Rule integration.

Originator information — natural person

• Full legal name.
• Identity number (for SA residents) or passport / foreign ID number.
• Date of birth.
• Residential address or country of birth.
• Distributed ledger address used for the transfer.
• Crypto-asset account number or transaction unique identifier (wallet address).
• Transaction details (date, amount).

Originator information — legal person

• Registered name.
• Registration number.
• Registered address.
• Distributed ledger address used for the transfer.
• Transaction details.

Counterparty CASP due diligence

Before transmitting Travel Rule information, RainFin performs due diligence on the counterparty CASP, including:

• Identification of the counterparty.
• Assessment of its ability to protect the confidentiality of the transmitted information.
• Assessment of whether the counterparty is identified pursuant to a UNSC resolution under section 26A(3) of the FIC Act.

Where the counterparty cannot or will not provide the required information, the Compliance Officer determines whether to proceed (with a documented rationale), to delay, or to file a section 29 report.

Retention

Travel Rule data is retained for at least five years under the records framework.

Last live Travel Rule exchange report

Trigger events outside the threshold-based tiers

Events that bring the Compliance Officer in regardless of tier, balance or activity level.

The following events trigger an immediate manual review by the Compliance Officer regardless of the customer's current KYC tier, balance or activity level:

• Confirmed sanctions match (true positive on any sanctions list).
• Confirmed PEP, FPPO, PIP or family-member or close-associate match.
• Geographic risk event — customer logs in from, transacts to, or otherwise interacts with a FATF black-listed or grey-listed jurisdiction or a jurisdiction subject to comprehensive US, EU or UK sanctions.
• Receipt of a section 27, section 32 or section 34 directive from the FIC.
• On-chain scanner identifies a customer wallet as connected (directly or by hops) to a darknet market, mixer, ransomware payment address, or known high-risk exchange.
• Structuring indicators — repeated sub-threshold transactions consistent with evasion of any threshold (R50,000, R100,000, R49,999, R19,999.99).
• Material adverse media event involving the customer, beneficial owner or controlling person.
• Material change in product holding (for example a Level 1 customer requesting tokenisation services).
• Single transactions exceeding R200,000 within a seven-day period.
• Use of mixing or privacy-coin patterns identified by on-chain scanning.
• Sumsub or SNTNL flags the customer through ongoing monitoring.

On-chain monitoring

Wallet address screening, hop tracing, mixer and darknet detection.

Every wallet address involved in a deposit or withdrawal is screened by SNTNL against:

• OFAC sanctions list (wallet addresses).
• UN sanctions list (where wallet addresses are listed).
• SNTNL's proprietary sanctions and high-risk database.
• Explorer labels for darknet markets, mixers, high-risk exchanges and flagged entities.

The on-chain scanner traces transaction hops to identify layering patterns where funds pass through multiple intermediary wallets to obscure origin.

Where a wallet address is flagged, the transaction is held pending Compliance Officer review.

Reporting to the FIC

What reports we file, when, and the operational SOP for each.

All reports are filed via the goAML portal. The Compliance Officer is the named filer; the Head of Operations is the back-up filer. Every report is reviewed and approved by the Compliance Officer before submission. The goAML inbox is monitored daily for section 27, 32 and 34 correspondence.

Cash Threshold Report (CTR)

Section 28 — cash transactions above R49,999.

When the obligation arises

A cash transaction above R49,999.99 is paid or received by RainFin. Cash means coin and paper money and travellers' cheques; it does not include cheques, drafts, electronic funds transfers, wire transfers or other means that do not involve the physical transfer of cash.

How a CTR actually gets filed at RainFin

1. Detection — automated, real-time

SNTNL by Ravencall ingests every transaction touching RainFin's controlled accounts in real time — banking feeds from Absa and FNB, crypto exchange APIs, payment rails. Cash deposits hitting any RainFin account are auto-detected by the banking-feed integration. SNTNL's rule engine flags any cash transaction above R49,999.99 within seconds of the credit landing.

2. Case opened — automatic

SNTNL auto-creates a Cloudlog ticket. Category: "Regulator — CTR". The ticket inherits the bank-feed transaction record, any reference data linking the deposit to a customer, the customer's Sumsub KYC record, and any prior SNTNL alerts on the same customer. The 3-day filing-deadline counter starts.

3. AI draft — automatic

Cloudlog's AI Co-Pilot drafts the goAML v5.0.2-compliant CTR XML from the linked data: customer identification from Sumsub, transaction data from SNTNL, RainFin's institutional registration data (AI/131104/00006, named filer is the current Compliance Officer). The XML draft sits in the Cloudlog ticket alongside an AI-generated summary of the case.

4. JR co-sign — where the customer is JR-onboarded

If the customer was onboarded through a JR partner (e.g. AVBOB Wallet customers), Cloudlog auto-routes a co-sign request to the JR partner's named Compliance Officer. See JR partnerships and co-signing. For CTR, the co-sign window is 24 hours (because of the 3-day filing deadline).

5. Compliance Officer approval — the human step

The Compliance Officer receives a high-priority alert in Cloudlog. The review covers: confirming the cash threshold was correctly identified; confirming the customer linkage is correct; confirming the CTR XML is factually accurate; confirming any JR co-sign is in place; approving the filing.

6. Filing — automated where possible

On approval, the goAML CTR XML is uploaded via the FIC portal in a one-click action from Cloudlog. The submission timestamp and the FIC reference number are captured automatically.

7. Record — automated

The goAML receipt PDF is attached to the Cloudlog ticket. The ticket carries the complete evidence chain and is retained for five years under FIC Act section 23.

8. Parallel STR consideration — automatic

Because RainFin does not normally accept cash, a cash deposit at this threshold is almost always also an STR scenario under section 29. SNTNL simultaneously raises a related STR alert; a linked Cloudlog ticket opens; the STR procedure runs in parallel. Where small cash amounts are deposited within the same day with the intention to avoid the CTR reporting obligation, those transactions are reported as STR, not as CTR.

9. Tipping-off — system-enforced

The customer is not informed. The Cloudlog ticket and the Slack visibility carry a tipping-off flag that restricts customer-identifying detail to the compliance function. The customer-facing app shows no signal.

Suspicious or Unusual Transaction Report (STR)

Section 29 — when knowledge or suspicion arises.

When the obligation arises

Knowledge or suspicion that a transaction or series of transactions involves proceeds of unlawful activity, is intended to evade reporting duties, has no apparent business or lawful purpose, involves a higher-ML/TF/PF-risk person (such as a foreign DPEP or close associate), is suspicious cross-border activity, relates to an offence under POCDATARA, may be relevant to SARS tax evasion investigation, or is being conducted to avoid a reporting duty.

The legal test under section 29 is that a person "knows or ought reasonably to have known or suspected" the facts giving rise to the obligation. A suspicion implies an absence of proof.

How an STR actually gets filed at RainFin

The end-to-end flow leads with system detection and AI-assisted drafting; the Compliance Officer's role is to approve, not to investigate from scratch.

1. Detection — automated, real-time

SNTNL by Ravencall monitors every fiat and crypto transaction in real time against the eight platform rules and the R1–R8 named monitoring rules. Where the composite risk score on a transaction is High — driven by behavioural deviation, structuring pattern, on-chain darknet or mixer match, velocity breach, jurisdictional anomaly, sanctions or PEP signal, or any combination of the five risk-model components — SNTNL raises a high-risk alert within seconds of the triggering event. There is no human detection layer for the primary case. Where an employee suspects an STR-relevant matter outside the SNTNL flow, see the employee suspicion playbook.

2. Case opened — automatic

SNTNL auto-creates a Cloudlog ticket. Category: "Compliance — STR consideration". The ticket inherits the SNTNL alert ID, the rule fired, the customer reference (held in a Compliance-only field per the tipping-off discipline in Cloudlog), the composite risk score and its component drivers, the on-chain analysis output where relevant, the customer's KYC tier and behavioural baseline from SNTNL, and a deadline counter (15 days from the time the suspicion arose, excluding weekends and public holidays).

3. AI draft — automatic

Cloudlog's AI Co-Pilot drafts the STR narrative from the linked data: the customer file in Sumsub, the SNTNL evidence chain, the on-chain analysis, the customer's transaction history and behavioural baseline, and the rule context. The draft narrative includes the structured fields required by goAML — customer identifying particulars, transaction particulars, grounds for suspicion (citing the specific section 29 element), actions taken so far, supporting evidence. The narrative sits in the Cloudlog ticket as the working draft.

4. JR co-sign — where the customer is JR-onboarded

If the customer was onboarded through a JR partner (currently AVBOB Wallet customers), Cloudlog automatically routes a co-sign request to the JR partner's named Compliance Officer via the secure cross-tenant channel. The JR Compliance Officer reviews the AI-drafted STR narrative in Cloudlog and co-signs within 48 hours. See JR partnerships and co-signing for the full protocol. If the JR Compliance Officer does not co-sign within 48 hours, RainFin files on the basis that the JR has been notified; the lack of co-sign is recorded in the ticket.

5. Compliance Officer review — the human approval step

The Compliance Officer receives a high-priority alert in Cloudlog and the compliance Slack channel. The Compliance Officer's review consists of: confirming the section 29 threshold is met; confirming the AI-drafted narrative is factually accurate and complete; confirming the supporting evidence is sufficient; confirming any required JR co-sign is in place; deciding to file or not to file. The decision is recorded in the Cloudlog ticket.

Where the Compliance Officer determines not to file, the reason is recorded against the SNTNL alert and against the Cloudlog ticket. The not-filed register is reviewed monthly by the Compliance Officer to confirm the threshold was correctly applied and to spot patterns suggesting under-reporting.

6. Filing — automated where possible, one-click where required

On approval, the goAML v5.0.2-compliant XML is generated. Currently the XML is uploaded via the FIC goAML web portal in a one-click action from Cloudlog (current state); the long-term target is fully programmatic filing if and when the FIC's goAML API supports it. The named filer is the current Compliance Officer per the firm's FIC registration (Contacts directory). The submission timestamp is captured automatically.

7. Record — automated

The goAML receipt PDF is retrieved and attached to the Cloudlog ticket. The Cloudlog ticket holds the complete evidence chain — original SNTNL alert, AI-drafted narrative, Compliance Officer approval, JR co-sign (where applicable), goAML reference number, retention timer set to five years from filing under FIC Act section 23. Searchable, audit-ready, with the AI-drafted findings approved by a named human before record creation.

8. Tipping-off — system-enforced

The customer is not informed at any stage. Cloudlog tickets categorised "Compliance — STR consideration" carry a system flag that restricts visibility to the compliance function. Customer-facing systems (Sumsub UI seen by Operations analysts, the RainFin app, the AVBOB Wallet interface) carry no surface signal that an STR has been filed. The customer's transactional access continues unless the Compliance Officer specifically determines otherwise or the FIC issues a section 34 directive.

Continuing the transaction

Filing an STR does not in itself require RainFin to stop a transaction. The transaction continues unless the FIC issues a section 34 directive to suspend, or unless the Compliance Officer determines that proceeding would itself constitute an offence.

Terrorist Property Report (TPR)

Section 28A — possession or control of property of a sanctioned or designated entity.

When the obligation arises

RainFin is in possession or control of property of: any entity that has committed or attempted to commit an offence as defined in POCDATARA; a specific entity identified in a UN 1267 sanctions list; or a person or entity identified in a TFS list as published on the FIC website.

How a TPR actually gets filed at RainFin

1. Detection — automated, continuous

Sumsub and SNTNL run continuous screening of the customer base against the TFS list, the UNSC consolidated list, OFAC SDN, EU Consolidated, HM Treasury OFSI and POCDATARA-designated entities. New TFS list publications trigger an immediate full-base re-screen within minutes. Any match — at onboarding, on transaction, on list update — surfaces as an alert.

2. True-positive determination — Compliance Officer judgment

The system flags possible matches. The Compliance Officer reviews the match in Cloudlog and determines true positive or false positive. This is a documented judgment call. False positives close in Cloudlog with the rationale recorded; true positives proceed.

3. Case opened — automatic

On true-positive determination, Cloudlog auto-creates an urgent ticket — category "Compliance — sanctions". The ticket inherits the screening match, the customer file from Sumsub, every related transaction from SNTNL, and the asset position (wallet balance + any in-flight transactions).

4. Freeze — automated

SNTNL freezes the customer's wallet at user level, applying the cross-wallet aggregation rule so the customer cannot transact across any linked wallets. The wallet shows no surface signal of the freeze to the customer (tipping-off discipline). Asset position at the moment of freeze is captured for the TPR.

5. AI draft — automatic

Cloudlog's AI Co-Pilot drafts the goAML TPR with the required institutional particulars (accountable institution name, registration number AI/131104/00006, address, type of business, named contact), the property description (asset type, amount, wallet address, transaction history), and the basis for identification as terrorist property (which list, which designation, screening match confidence).

6. JR co-sign — where the customer is JR-onboarded

If the customer was onboarded through a JR partner (AVBOB Wallet), Cloudlog auto-routes a co-sign request to the JR partner's Compliance Officer. Co-sign window for TPR: 24 hours (because of the 5-day filing deadline). See JR partnerships and co-signing.

7. Compliance Officer approval and Key Individual escalation

The Compliance Officer reviews the AI-drafted TPR, edits if needed, and approves. The Key Individual is informed of the freeze and the pending TPR. External counsel is engaged for the freeze process and any FIC communication beyond the TPR itself.

8. Filing — within 5 days

The goAML TPR XML is filed via the goAML portal. The submission timestamp and FIC reference are captured automatically.

9. Onward — banking partner notification

The customer's banking partner is informed of the positive match. The bank may conduct further investigation and consider freezing the bank account. The notification is recorded in the Cloudlog ticket.

10. Record — automated

The Cloudlog ticket holds the complete evidence chain — screening match, freeze action, AI-drafted TPR, Compliance Officer approval, JR co-sign (where applicable), Key Individual notification, banking partner notification, goAML reference, retention timer set to 5 years from filing. Records cannot be destroyed during the retention period.

11. Tipping-off — system-enforced

The customer is not informed at any stage. The freeze appears silent in the customer-facing app. The Cloudlog ticket and any communications are restricted to the compliance function.

International Funds Transfer Report (IFTR)

Section 31 — cross-border electronic transfers above R19,999.99.

When the obligation arises

An electronic transfer of funds in or out of South Africa of an amount exceeding R19,999.99, on behalf of or on the instruction of another person — distinct from RainFin's own treasury movements which are not in scope.

How an IFTR actually gets filed at RainFin

1. Detection — automated, real-time

SNTNL monitors every electronic transaction in real time against the R19,999.99 cross-border threshold. The detection logic captures direction (out of SA / into SA), value, currency, and whether RainFin is acting on behalf of another person (vs RainFin's own treasury movement).

2. Case opened — automatic

SNTNL auto-creates a Cloudlog ticket. Category "Regulator — IFTR". The ticket inherits the transaction record, the customer reference, the counterparty information, and the 3-business-day filing-deadline counter.

3. AI draft — automatic

Cloudlog's AI Co-Pilot generates the goAML v5.0.2 IFTR XML. The XML auto-populates with the customer identification data from Sumsub, the transaction particulars from SNTNL, and RainFin's institutional registration data. Originator and beneficiary fields conform to the FIC IFTR specification.

4. JR co-sign — where the customer is JR-onboarded

For JR-onboarded customers, Cloudlog routes a co-sign request to the JR partner's Compliance Officer. Co-sign window: 48 hours. See JR co-signing.

5. Compliance Officer approval

The Compliance Officer reviews the AI-drafted IFTR XML and approves. Single human decision point.

6. Filing — within 3 business days

One-click upload from Cloudlog to the goAML portal. Submission timestamp and FIC reference captured automatically.

7. SARB exchange control — parallel reporting

Where the cross-border crypto flow also engages the exchange control regulations, a parallel report is generated for the Authorised Dealer arrangement (currently via Absa for fiat-leg flows). The Compliance Officer maintains the operational interface with the relevant Authorised Dealer. SARB reporting is logged in the same Cloudlog ticket for the audit trail.

8. Record — automated

The Cloudlog ticket holds the complete evidence — original transaction, goAML XML, FIC reference, SARB report reference (where applicable), Compliance Officer approval, JR co-sign. Retention 5 years.

FIC information requests and directives

Sections 27, 32 and 34 — what we do when the FIC asks or directs.

How FIC requests and directives actually get handled at RainFin

1. Detection — goAML inbox monitoring

The goAML inbox is monitored continuously by the integration. Incoming messages from authorised FIC representatives are flagged immediately. The morning routine confirms a clean inbox at 09:00 SAST each business day.

2. Classification — system-assisted

Cloudlog's AI Co-Pilot classifies the incoming message: section 27 (information request), section 32 (additional information following a prior report), section 34 (intervention directive — freeze or suspend). Each category has its own ticket type, SLA, and escalation path.

3. Case opened — automatic, with appropriate routing

Cloudlog auto-creates a ticket:

• Section 27 — category "Regulator — s27"; routes to Compliance Officer; SLA per the request specification.
• Section 32 — category "Regulator — s32"; links to the original Cloudlog ticket for the underlying report; routes to Compliance Officer.
• Section 34 — category "Regulator — s34 — URGENT"; routes simultaneously to Compliance Officer and Key Individual; freeze action prepared immediately.

4. Section 34 freeze — actioned same business day

Where the message is a section 34 directive, the freeze is actioned the same business day. SNTNL applies the freeze at user level across all linked wallets. The Cloudlog ticket records the freeze action timestamp, the affected customer (in the Compliance-only field), the directive period, and any specific transactions identified. External counsel is engaged for communications back to the FIC beyond the freeze confirmation.

5. Record identification — system-assisted

For section 27 and section 32 requests, Cloudlog identifies the relevant records: customer file from Sumsub, transaction history from SNTNL, prior reports from goAML, internal correspondence from email archive, prior Cloudlog tickets on the same customer. The full record set is assembled in the ticket.

6. AI draft response — automatic

Cloudlog's AI Co-Pilot drafts the response, addressing each numbered question in the FIC's request. The draft cites the source records and includes annexures with the supporting evidence.

7. Compliance Officer approval — with external counsel where required

The Compliance Officer reviews the draft. Where the matter touches privilege, scope beyond the FIC's stated powers, or material customer-detriment risk, external counsel reviews before response.

8. Filing — via goAML

Response submitted via goAML or the channel specified by the FIC. Confirmation of receipt logged automatically.

9. Section 34 follow-through

For section 34 directives: the Cloudlog ticket remains open for the full directive period. All impacted transactions are frozen. Status reports to the FIC are filed against the same ticket. At directive expiry, the freeze is lifted only on FIC confirmation or directive expiry; the Compliance Officer assesses residual risk.

10. Record — automated

The Cloudlog ticket retains the FIC request, the identified records, the draft and approved response, the goAML submission, and any FIC follow-up. Retention 5 years.

Penalties

Failure to comply with a section 27 or 32 request is an offence carrying up to 15 years' imprisonment or a fine of up to R100 million, in addition to administrative sanctions under section 61A. The same penalties apply to non-compliance with a section 34 directive.

Tipping-off

The disclosure prohibition under section 29(2A) of the FIC Act.

What this means in practice

• Do not tell the customer that an STR has been filed.
• Do not tell the customer that they are under investigation.
• Do not tell anyone else outside the firm's compliance function.
• Do not discuss the report in any informal channel — not Slack DM, not email, not corridor conversation.
• Where a customer relationship is being terminated because of an STR, do not give the customer the real reason.
• Do not give "no comment" or any signal that hints at the report.

Permitted disclosure

Disclosure is permitted only within the scope of a person's powers and duties under any legislation; for the purpose of carrying out the FIC Act; for the purpose of legal proceedings; or in terms of an order of court.

Penalty

Contravention carries criminal penalties of up to 15 years' imprisonment or a fine of up to R10 million.

Legal protection for the reporter

No legal action, whether criminal or civil, can be instituted against a person who complies in good faith with a reporting obligation. The identity of the reporter is protected and the reporter cannot be forced to give evidence in criminal proceedings concerning the report.

Records

Sections 22, 22A and 23 of the FIC Act — what we keep, where, and for how long.

RainFin keeps records for at least five years from the date of the transaction, the termination of the business relationship, or the filing of a report (whichever is later). Records may not be destroyed before the expiry of the five-year retention period.

Minimum record set

• The identity of the customer and, where applicable, the customer's agent or principal; the means by which the identity was established; the documents or other evidence relied on.
• The nature and intended purpose of the business relationship and the source of funds for any transaction.
• Every transaction — date, parties, amounts, currency, nature, account references, business correspondence.
• The TFS screening output for every customer (screenshot or system-generated record), and any decision on a possible match.
• Every STR, CTR, TPR, IFTR or other FIC report filed, with the supporting evidence and the Compliance Officer's decision record. The goAML submission record is downloaded after each filing and retained.
• Every decision not to file a report and the reasons.
• Travel Rule data — originator and beneficiary information transmitted or received.
• Ongoing CDD, EDD outcomes, Compliance Officer sign-offs, Compliance Risk Committee decisions.
• Training records — attendance registers, presentations, assessments where applicable.
• Employee screening records — proof of identity, employment history, qualifications, references, criminal record, credit screening, TFS screening, employee screening questionnaire outcomes.

Storage systems

Records may be reproduced as a certified extract or printout and on production are admissible as evidence of any fact contained in them of which direct oral evidence would be admissible.

Employee training and screening

FICA training, pre-employment screening, ongoing screening by role risk level.

Training

Every new employee completes initial FICA training within 30 days of appointment. All other employees complete annual refresher training. Additional training is delivered after any material amendment to this programme and on identification of a training need.

Training covers:

• The customer due diligence process.
• Sanctions, PEP and adverse media screening.
• Recognition of suspicious activity.
• The duty to report.
• The tipping-off prohibition.
• The use of Sumsub and SNTNL in daily operations.
• Role-specific deep dives for the Operations and Compliance teams.

Training attendance is logged in the training register. Where appropriate, the training includes a written or verbal assessment.

Pre-employment screening

Every prospective employee is screened for competence (skills, knowledge, expertise) and integrity (honesty and moral principles) before appointment, in line with the Labour Relations Act, the Basic Conditions of Employment Act, and POPIA. Consent under POPIA is obtained before screening.

Ongoing screening matrix

Screening checks by intensity

TFS screening of employees

Prospective employees are screened against the TFS list before appointment. Existing employees are screened against the TFS list on each update to the list. Employees who are no longer employed by RainFin are not screened.

Awareness and reporting

Employees who suspect a suspicious or unusual situation report it to the Compliance Officer without delay. Employees do not discuss reports or suspected reports with the customer or with anyone else (tipping-off prohibition). RainFin protects employees who report in good faith — the FIC Act provides legal protection and the firm's whistleblower channel is available.

Outsourcing — Sumsub and Ravencall

PCC 44A disclosure for the two material compliance functions outsourced by RainFin.

RainFin outsources two material compliance functions to specialist service providers. RainFin retains the regulatory obligation in each case; outsourcing the operational performance does not outsource the obligation.

Due diligence on providers

Sumsub and Ravencall have each been assessed by the Compliance Officer for fitness to perform the outsourced function. The assessments cover regulatory experience, data protection compliance (POPIA operator agreements), information security posture, business continuity and exit, and concentration risk. The assessments are refreshed at least annually.

Monitoring

The Compliance Officer reviews each provider's performance at least quarterly. The review covers volume, throughput, error rates, escalation handling, regulatory updates, incident logs, and compliance with the contracted SLA. Material issues are noted to the Board.

The Sumsub configuration runs two distinct profiles. One profile holds RainFin's own customer base; the other holds BMA's. This was confirmed by the Finance Manager to CAEP on 28 February 2026 in the context of a TFS-list screening clarification. The two profiles are operated independently of each other; customer data is not shared between them. The tenant identifier (bma.network_56176) is a historical naming convention from when BMA operated the platform — RainFin operates its profile directly. There is no intermediary processor for RainFin's customer KYC. Renaming the tenant identifier to a RainFin-aligned one is in progress.

Manual fallbacks

Cross-border perimeter

RainFin operates from South Africa and serves South African residents only.

The firm does not solicit customers in the United Kingdom, the European Union, or the United States, and treats inbound interest from those jurisdictions on a reverse-solicitation basis only where the Compliance Officer is satisfied that no marketing has occurred.

Monitoring of foreign developments

The Compliance Officer monitors regulatory developments in those jurisdictions on a continuous basis:

• UK FCA cryptoasset financial promotions and the developing fiat-backed stablecoin regime.
• EU MiCA Title III and Title IV requirements.
• US SEC, CFTC and FinCEN positions on crypto assets and stablecoins.
• OFAC sanctions activity.

Any product or service expansion that contemplates a customer base in those jurisdictions is subject to the new-product process and to external counsel sign-off before launch.

US persons

New products and material change

The gating process for any new product, vendor, geography or distribution channel change.

Every new product, material change to an existing product, new vendor, new geography or material change in distribution channel is assessed by the Compliance Officer against this programme before launch.

What the assessment records

• The activity in plain English.
• The target customers.
• The regulatory perimeter analysis.
• The impact on the licence stack.
• The AML / CFT / CPF impact.
• The data protection impact.
• The operational resilience and outsourcing impact.
• The residual risk rating.
• The decision — proceed, proceed with conditions, or not proceed.

The output is retained in the new-product register held by the Compliance Officer and reported to the Board at the next meeting. The Risk Matrix and Annexure A are updated as required.

Annexure A — Risk indicators

The indicators used in customer risk rating and alert calibration.

Where an indicator is identified, the relevant factor score is set to high (3); a customer's overall score is the highest single factor score.

Geographic risk

• Customer residence, address, IP or transactional counterparty in a FATF black-listed or grey-listed jurisdiction.
• Customer residence, address, IP or transactional counterparty in a jurisdiction subject to comprehensive US, UK or EU sanctions.
• Customer residence, address, IP or transactional counterparty in a jurisdiction listed in the FIC NRA as a high-risk source or destination.
• Customer is a foreign national; address or registration in a foreign jurisdiction.
• Use of intermediaries based outside South Africa.
• Cross-border money flows particularly to or from high-risk countries.

Customer risk

• Foreign politically exposed person, family member or known close associate.
• Confirmed sanctions match, court order or POCDATARA designation.
• Domestic prominent influential person or foreign prominent public official with additional risk indicators.
• Customer cannot or will not provide standard CDD; provides doubtful, vague or partial identification.
• Customer ceases business relationship on request for CDD.
• Customer is anonymous or uses an apparent false or fictitious name.
• Customer is a juristic person whose beneficial ownership cannot be fully established.
• Complex juristic structure — multi-layered ownership, nominee shareholders or directors.
• Customer with adverse media reports, prior fraud or financial misconduct allegations.
• Customer with prior criminal conviction.
• Stated occupation or business inconsistent with the size or pattern of transactions.

Product and channel risk

• Crypto-asset transfer to or from an unhosted wallet.
• Customer's wallet address identified by on-chain scanning as connected to a darknet market, mixer, ransomware or high-risk exchange.
• Customer holds yield-bearing balances above the Level 2 threshold.
• Customer requests a tokenised real-world asset product.
• Use of privacy coins (Monero, Zcash) or privacy-enhancing technologies.
• Non-face-to-face onboarding combined with elevated other risk indicators.
• Use of third-party payments or intermediaries.

Behavioural and crypto red flags

• Structuring — sub-threshold transactions consistent with evasion of the R50,000, R100,000, R49,999 or R19,999.99 thresholds.
• Velocity — volume materially exceeds the customer's baseline.
• Unusual time-of-day or geographic pattern.
• New or previously unknown withdrawal destination wallet.
• Multiple failed authentication attempts followed by a successful transaction.
• Device or IP anomaly.
• Activity inconsistent with declared source of funds.
• Mixing or privacy-coin patterns.
• Inbound transfer from a counterparty CASP that cannot provide Travel Rule data.
• Adverse media event involving the customer or BO.
• Sudden spike in transaction volume.
• Repetitive small transactions inconsistent with the customer's profile.
• Round-number cash-equivalent deposits or withdrawals.
• Customer attempts to alter a transaction after being asked for CDD.
• Customer requests early termination of a position with no apparent rationale.
• Customer is quick to volunteer that funds are "clean" or "not laundered".

Annexure B — Inherent risk matrix

The inherent ML/TF/PF risk for each material risk factor, before controls are applied.

The matrix is reviewed at least annually and on every material change to the business. Each factor is scored low / medium / high; the overall inherent risk is the highest single factor score.

Residual risk. The residual risk matrix, held by the Compliance Officer, records the same factors with the controls in this programme applied. Residual risk is reviewed at least annually and on every material change to the controls.

Annexure C — CDD and KYB document checklists

What we collect for each entity type.

C.1 — South African natural person

• Identity document (green ID book or smart ID card) or passport.
• Biometric liveness check.
• Full name, date of birth, country of birth, country of residence.
• Contact details — mobile, email.
• Tax identification number (where applicable).
• Residential address (Level 2+) — utility bill, bank statement, lease or official correspondence not older than three months.
• Source of funds declaration (Level 2+).
• Proof of source of funds (Level 3) — salary slip, sale documents, business income evidence, inheritance.
• FICA self-declaration questionnaire.
• Sanctions, PEP, adverse media screening output.

C.2 — Foreign national

• Passport (machine-readable zone verified).
• Country of issue verification; visa or permit status where relevant.
• All items listed in C.1.
• Additional screening against the country of residence's regulatory regime; assessment against FATF lists.
• Enhanced source-of-funds verification where the home jurisdiction is on a FATF or sanctions list.

C.3 — South African company

• Memorandum of Incorporation (or certified extract).
• CIPC registration certificate and latest CIPC disclosure.
• Share register or shareholder schedule.
• Resolution authorising the relationship with RainFin and the authorised signatories.
• Proof of registered address.
• Tax clearance certificate.
• Identification of every director under C.1.
• Identification of every beneficial owner under the 5% test.
• Confirmation of any nominee shareholders or directors and the natural person ultimately controlling them.

C.4 — Close corporation

• Founding statement (CK1) and any amended founding statement (CK2).
• CIPC registration certificate.
• Member register.
• Resolution authorising the relationship.
• Proof of registered address.
• Tax clearance certificate.
• Identification of every member under C.1.

C.5 — Foreign company

• Equivalent constitutional documents from the country of incorporation, certified by notary or apostille.
• Certified extract of foreign registration.
• Ownership chain documentation, including identification of any intermediary entities.
• Identification of every director under C.1 or C.2.
• Identification of every beneficial owner under the 5% test.
• Verification of foreign sanctions exposure and FATF country assessment.

C.6 — Trust (South African)

• Trust deed and any amendments.
• CIPC letter of authority for the trustees.
• Trustee resolution authorising the relationship.
• Identification of the founder under C.1 or C.2.
• Identification of every trustee under C.1 or C.2.
• Identification of every named beneficiary; for class-based beneficiaries, particulars of how beneficiaries are determined.
• Identification of any natural person authorised to act on behalf of the trust.

C.7 — Trust (foreign)

• Letter of authority or other official document from the competent trust registering authority.
• Certified trust deed.
• All items listed in C.6.
• Assessment of the country of registration against FATF lists.

C.8 — Partnership

• Partnership agreement.
• Identification of every partner — regardless of percentage ownership.
• Identification of every natural person authorised to act on behalf of the partnership.
• Identification of the natural person(s) who exercise executive control.
• For en commandite and anonymous partnerships, identification of the silent partner(s).

C.9 — Non-profit organisation

• NPO registration certificate.
• Founding document.
• Trustee or director register.
• Resolution authorising the relationship.
• Identification of each trustee or director under C.1 or C.2.
• Assessment of the source of funding (donor base) for ML/TF/PF risk.
• Where applicable, registration as a Public Benefit Organisation with SARS.

C.10 — Sole trader

• Identification of the natural person under C.1 or C.2.
• Business registration (if any).
• Tax registration.
• Description of the business activity.
• Verification of business address.

C.11 — Organ of state or public institution

• Establishment legislation or constitutional instrument.
• Identification of authorised signatories under C.1 or C.2.
• Resolution authorising the relationship.
• Verification of the responsible official.

Annexure D — Onboarding questionnaire structure

The four sections of the Sumsub onboarding flow.

D.1 — Customer identification

• Full legal name (and trading name, if applicable).
• Identification number / Company registration number.
• Date of birth / Date of incorporation.
• Residential / Registered address.
• Contact number and email address.
• Citizenship / Country of incorporation.
• Tax Identification Number and tax jurisdictions.

D.2 — Business relationship purpose

• Purpose and intended nature of the business relationship.
• Expected types of services to be used.
• Anticipated transaction types, frequency and volumes.
• Expected value of future transactions.
• Source of funds.
• Source of wealth (Level 3 and high-risk).

D.3 — Ownership and control (juristic persons)

• Details of all beneficial owners (names, ID numbers, percentage ownership).
• Details of authorised signatories.
• Ultimate holding company.
• Nominee shareholder / director disclosure.

D.4 — PEP / PIP / FPPO and regulatory

• Are you, or any related party, currently or previously, a domestic or foreign PEP, PIP or FPPO?
• If yes — position, country, term of office, source of funds.
• Do you perform activities under any sub-category of the FAIS Act?
• Are you currently regulated by any financial services authority?
• Do you have your own RMCP / AML policies (juristic persons)?
• Have you been or are you currently being investigated or sanctioned for financial misconduct?

Annexure E — Ongoing CDD consistency test

The six-section review applied at the relevant frequency.

Frequency: low risk — every 2 years; medium — annually; high — quarterly. The review is recorded in the customer file and signed off by the Compliance Officer for high-risk customers.

Section 1 — Identity and profile consistency

Have there been any changes to legal name, legal form, identity documentation, address, contact information, nature of business or occupation, source of funds or wealth, country of domicile?

Section 2 — Beneficial ownership and control

Are all previously declared UBOs still valid? Has any person or entity holding 5% or more of ownership, voting rights or effective control changed?

Section 3 — Transactional behaviour consistency

Are the customer's actual transactional patterns aligned with the documented expected behaviour? Any unusual spikes in volume or value? Transactions inconsistent with profile or jurisdiction? New or unusual counterparties, intermediaries or payment channels? Transactions involving high-risk countries or products?

Section 4 — Sanctions, PEP and adverse media review

Does the customer or any related party appear on updated sanctions lists, PEP databases or adverse media? If yes, EDD is initiated.

Section 5 — Risk profile reassessment

Based on the above, does the overall risk profile remain the same, increase, or decrease? Was a formal re-risk rating conducted?

Section 6 — Compliance declaration

All required documentation updated? Any STR filed? Recommended action — no action, update records, escalate for EDD, file STR, suspend or terminate.

Annexure F — Definitions

Defined terms used in this programme.

Annexure G — Vendor register

Every material third-party service provider that supports the controls in this programme.

The Compliance Officer reviews this register at least quarterly. Each vendor has a written contract, an operator agreement under section 21 of POPIA, and a documented assessment under PCC 44A.

Annexure H — Referenced policies and procedures

Standalone operational policies that support this programme.

Change log

Every revision of this programme, with the date, summary of change, and approving authority.

Daily compliance routine

What every member of the compliance team does, in order, every business day.

What the system has already done by 08:30 SAST

1. SNTNL has run continuously overnight. Every transaction monitored. Low-risk alerts auto-resolved. Medium-risk alerts in the Operations queue. High-risk alerts in the Compliance Officer queue with AI-drafted findings.
2. Sumsub has run continuously. Ongoing ID monitoring, adverse media feed, PEP screening. Hits surface as Cloudlog tickets categorised by severity.
3. TFS list updates have been ingested. The FIC TFS automated email triggers immediate full-base re-screen. OFAC, HM Treasury, EU lists checked. Any match becomes a high-risk Cloudlog ticket.
4. goAML inbox has been monitored. Any incoming section 27, 32, 34 message classified by Cloudlog AI and routed.
5. Cloudlog has opened tickets for every overnight event. AI Co-Pilot drafts are in progress.
6. The Daily Compliance Brief has been generated. In the Compliance Officer's inbox at 08:30 SAST with the summary, the urgent items, the drafts pending approval.

09:00 SAST — Compliance Officer at the desk

1. Open the Daily Compliance Brief. Read the urgent banner. If empty, the day proceeds normally. If populated, action the urgent items first.
2. Review the high-risk Cloudlog queue. The AI-drafted findings are pre-populated. Compliance Officer's role is to approve, edit, or reject — not to investigate from scratch.
3. Sign off pending regulatory filings. STR, CTR, TPR, IFTR drafts ready. One-click approval and filing via goAML.
4. Sign off pending EDD outcomes. L3 step-up verifications, sanctions match determinations, high-risk customer approvals.
5. Confirm goAML inbox is clean. Any section 27 / 32 responses drafted overnight reviewed and dispatched.
6. Acknowledge the brief and open items roll forward to tomorrow's brief.

09:00 SAST — Head of Operations at the desk

1. Triage the Operations Cloudlog queue. Medium-risk alerts, customer onboarding queries, Sumsub flow issues, document review escalations.
2. Confirm SNTNL is healthy. Any vendor incidents from overnight are flagged in the brief; outage procedure applies if material.
3. Banking partner inbox. Any DD requests, periodic review notices.
4. Escalate to Compliance Officer. Anything that crosses the medium → high threshold during triage.

During the day — exception-based human work

• SNTNL alerts continue to arrive in real time. Auto-resolved if low; routed if medium; escalated if high.
• Customer onboarding — Sumsub flow runs continuously; EDD escalations land in Cloudlog.
• Customer step-ups — R50k and R100k triggers fire and step-up flows initiate automatically; only exceptions reach humans.
• Regulator correspondence — any incoming section 27 / 32 / 34 opens a Cloudlog ticket and routes to the Compliance Officer.
• Customer communications — terminations, declines, EDD requests. AI-drafted; Compliance Officer-approved before sending.

End of day — 17:30 SAST

Cloudlog runs the day's closeout check. Confirms no open high-risk alerts; no overdue STR drafts; no open regulator correspondence. The check is automated; the Compliance Officer reviews the summary and signs off. Anything still open rolls into tomorrow's brief automatically.

Weekly compliance routine

The cadence checks that happen every week.

The systems run continuously through the week. The weekly cadence is the cadence of human review on what the systems have already done.

Monday — week setup

The Monday morning daily brief includes the previous week's compliance metrics auto-generated from SNTNL, Cloudlog and goAML — alert volume, alerts closed, STRs filed, EDD outcomes, customer terminations. The 09:00 SAST status meeting (Head of Operations, Compliance Officer, Key Individual) reviews the auto-generated weekly summary and confirms the week's open items. The Compliance Calendar surfaces the week's scheduled training, vendor reviews and regulator engagements as Cloudlog tickets.

Mid-week — every Wednesday

• Reasons-not-to-file register review. Cloudlog generates the auto-summary of every alert not filed as an STR in the week, with the AI's risk-pattern analysis. The Compliance Officer reviews to confirm the threshold was correctly applied and to spot under-reporting patterns.
• Vendor performance check. The Vendor performance live evidence page auto-refreshes. Sumsub throughput, error rates, escalation handling. Ravencall alert volume, rule firing rates, false-positive rates.
• High-risk customer watch list review. SNTNL surfaces the week's activity on every high-risk customer in a single Cloudlog ticket. The Compliance Officer reviews.

Friday — week close

• End-of-week summary to the Key Individual — auto-generated; covers material events of the week.
• Friday-evening TFS list update confirmation — system check, no manual action required unless a discrepancy is flagged.
• Training delivery log auto-updates from the LMS.
• Outstanding STR review — Cloudlog surfaces any STR triggered this week and not yet filed; deadline counters visible. Filing plan for Monday at the latest where applicable.

Monthly compliance cadence

Monthly tasks owned by the Compliance Officer.

First week of the month

• Monthly compliance report to the Key Individual — auto-generated by Cloudlog from the month's data: alert volume, STR / CTR / IFTR / TPR filings, EDD decisions, customer terminations, vendor performance, training delivered, open items. Compliance Officer reviews and signs off; system delivers to Key Individual.
• Risk indicator refresh. AI Co-Pilot reviews Annexure A indicators against the previous month's actual alert experience and proposes additions or modifications. Compliance Officer approves any changes.
• Training delivery. Cloudlog surfaces any pending refresher training as tickets; staff complete via Masthead's LMS.

Mid-month

• Internal audit sample review. Cloudlog auto-selects a random sample of onboarding files, EDD decisions and reporting decisions for review. Compliance Officer reviews for completeness and consistency with this programme.
• High-risk customer file refresh. Cloudlog auto-surfaces files due for quarterly refresh. AI Co-Pilot pre-populates the refresh checklist.
• Adverse media full sweep. SNTNL's monthly full-base adverse-media sweep runs automatically. Compliance Officer reviews any hits; routine confirmations on no hits.

Last week of the month

• Board pack metrics. If the Board meets the following month, Cloudlog auto-compiles the compliance metrics pack — alert distribution, filings, vendor performance, open items.
• Vendor performance report. Live evidence page (Vendor performance) is the source of truth; Compliance Officer reviews monthly trend and flags material issues.
• Regulatory horizon scan. AI Co-Pilot surfaces new FIC, FSCA, SARB notices; FATF mutual evaluations; offshore developments. Material items flagged to the Key Individual.

Quarterly review cycle

The deeper reviews that run every three months.

Quarterly cadence reviews the systems' output, not the underlying work — the systems run continuously; the quarter is the cadence of formal oversight.

Q1, Q2, Q3, Q4 — each quarter

• Quarterly Board report. Cloudlog auto-compiles the Board pack from the quarter's data — compliance posture, programme operation, material events, regulatory developments, vendor performance, residual risk movement. Compliance Officer reviews and signs off; Key Individual presents to the Board.
• Vendor formal review (PCC 44A). Sumsub and Ravencall reviewed against SLA, throughput, incident logs, sub-processor changes, concentration risk, exit readiness. Live evidence page is the source; Compliance Officer's quarterly note formalises the position.
• Risk matrix review. Inherent and residual risk matrices reviewed. AI Co-Pilot highlights material changes — new product, new vendor, new geography, material rule firing patterns — for Compliance Officer attention.
• High-risk customer file refresh. Every high-risk customer file refreshed at the quarterly cadence (section 5.5). Cloudlog surfaces all due files as tickets; AI Co-Pilot pre-populates each refresh.
• Programme amendment. Minor corrections by the Compliance Officer; material amendments queued for Board approval. Each amendment recorded in the RMCP version log.
• Banking partner annual review preparation. Q4 specifically — banking partner annual periodic reviews tend to fall here; the KYB pack is refreshed in advance.

Annual compliance calendar

The year at a glance — what we do, when, and who owns it.

Playbook — Sanctions match found

A possible match has been found on a sanctions list. Here's what to do.

Step 1 — System detection and triage

Sumsub or SNTNL raises the possible match in real time. Cloudlog auto-creates an urgent ticket (category "Compliance — sanctions"). The ticket inherits the match record, the source list (UNSC TFS, OFAC SDN, EU Consolidated, HM Treasury OFSI, FIC TFS), the matched person's identifiers, and the comparison against the customer's Sumsub record (name spelling, date of birth, ID number, address, nationality, known aliases). SNTNL automatically pauses any in-flight transaction for the customer pending determination.

Step 2 — True positive or false positive — Compliance Officer judgment

This is the human-decision step. AI Co-Pilot pre-populates the comparison and surfaces a confidence score, but the determination is the Compliance Officer's.

1. Where every identifier matches — treat as true positive until evidence shows otherwise. Skip to Step 3b.
2. Where the name matches but other identifiers differ — review the source list's full record and consider commissioning a public-records search. The AI Co-Pilot can run automated cross-references with available open-source data.
3. Record the determination in Cloudlog with reasons. Include the data points compared and the source list reference. Both false-positive and true-positive determinations are retained for 5 years.

Step 3a — False positive

1. Document the reason for the false-positive conclusion.
2. Onboarding or transaction may continue.
3. Note the false-positive flag on the customer file so the same match does not require re-investigation on subsequent screenings.
4. Confirm with the Compliance Officer for high-confidence cases; for any uncertainty, escalate.

Step 3b — True positive

1. Open a Cloudlog ticket. Category: Compliance — sanctions. The ticket is the case of record for everything that follows. See Incident response — Cloudlog.
2. Do not proceed. Do not establish a business relationship, conclude a single transaction, facilitate, advise, release payments, or give any economic support.
3. Freeze any assets under RainFin's control under sections 26A–26C.
4. File the TPR via goAML within 5 days. Use the TPR procedure.
5. Inform the customer's bank of the positive match. The bank may conduct further investigation and consider freezing the customer's account.
6. Inform the Key Individual.
7. Engage external counsel for the freeze process and any communications with the FIC beyond the TPR.
8. Do not inform the customer of the match — tipping-off prohibition (section 29(2A)).
9. Document everything on the customer file with timestamps. The decision record is retained for at least 5 years from the freezing event.

Step 4 — Aftermath

• Record the event in the compliance event log.
• Report at the next Board meeting.
• Review whether the same pattern could have been detected earlier — feed back into the SNTNL rule set if appropriate.

Playbook — STR triggered by SNTNL or an employee

SNTNL or an employee has raised a suspicion. Here's the procedure.

Step 1 — Capture the suspicion

1. If raised by SNTNL — pull the alert with all evidence (rule fired, transaction details, customer profile, behavioural deviation).
2. If raised by an employee — capture the observation in writing immediately. Do not discuss with the customer or with anyone outside the compliance function.
3. Time-stamp the moment of suspicion. The 15-day clock starts here.

Step 2 — Compliance Officer review (in Cloudlog)

Where the alert came from SNTNL at high-risk score, a Cloudlog ticket has already been opened automatically (see Incident response — Cloudlog). Where the alert came from an employee, the Compliance Officer opens the ticket manually. The Compliance Officer's review of the section 29 threshold, and every step that follows, happens against the Cloudlog ticket as the case of record.

1. The Compliance Officer assesses whether the section 29 threshold is met — does the firm know or reasonably ought to have known or suspected the facts identified?
2. Consider the customer history, source of funds, transaction pattern, jurisdictional risk, and any related alerts.
3. Document the assessment and the conclusion. Where the conclusion is not to file, see step 3a.

Step 3a — Decision not to file

1. Record the reason on the alert in SNTNL.
2. The reason is reviewed by the Compliance Officer monthly as part of the not-filed register check.
3. Customer relationship continues unless other concerns warrant termination.

Step 3b — Decision to file

1. SNTNL generates the AI-narrative draft. The Compliance Officer edits to ensure facts and tone are correct.
2. STR is filed via goAML within 15 days.
3. The goAML submission receipt is downloaded and retained.
4. The customer is not informed — tipping-off prohibition.
5. The decision and the filing are recorded in the compliance event log.

Step 4 — After filing

• The transaction continues unless the FIC issues a section 34 directive to suspend. Filing an STR does not in itself require RainFin to stop a transaction.
• The Compliance Officer monitors the goAML inbox for a section 32 additional information request following the STR.
• If the customer is to be terminated as a result of the STR, see Terminating a relationship. The customer is not given the real reason.
• If the Key Individual needs to know — yes, always notify on material STRs. The notification is itself confidential.

Step 5 — Lessons

At the next monthly review, the Compliance Officer considers whether the SNTNL rule set should be tuned in light of this case.

Playbook — Structuring detected

SNTNL has flagged a pattern of sub-threshold transactions consistent with evasion of a reporting or step-up threshold.

Why this matters

Structuring is the deliberate breaking-down of a transaction into multiple sub-threshold parts to evade a reporting obligation or a control. It is treated as an STR scenario — not as a CTR — and is the explicit reason RainFin runs Rule 7 in SNTNL.

Step 1 — System detection

SNTNL Rule 7 monitors every transaction against the structuring patterns: rapid consecutive sub-threshold transactions, multiple small deposits or withdrawals targeting the R5,000 / R19,999.99 / R49,999 / R50,000 / R100,000 thresholds, repeated attempts after failure. Cross-wallet aggregation is applied automatically — patterns split across linked wallets are detected at the user level.

Step 2 — Cloudlog ticket auto-opens

SNTNL raises a high-risk alert and Cloudlog auto-creates a ticket — category "Compliance — STR consideration" or "Compliance — sanctions structuring" depending on the threshold being evaded. The ticket inherits the full transaction pattern (the sequence of sub-threshold movements), the customer reference, the cross-wallet linkage analysis, and a draft STR narrative.

Step 3 — Immediate containment — automated

• SNTNL applies throttling on the customer's account.
• Cooling-off period applied — subsequent transactions held for review.
• Step-up authentication required on next transaction.
• The customer's risk rating is automatically elevated to high.
• No surface signal to the customer — tipping-off enforced.

Step 4 — Compliance Officer review — the human step

1. The Compliance Officer reviews the AI-drafted STR narrative and the SNTNL evidence chain.
2. Considers source of funds declaration, transaction frequency, the threshold being evaded, and the customer history.
3. Determines true structuring vs natural behaviour pattern. False positives close in Cloudlog with rationale.
4. Where true structuring is found, approves the STR for filing.

Step 5 — JR co-sign and filing

Where the customer is JR-onboarded, the JR partner's Compliance Officer co-signs within 48 hours. The STR is filed via goAML within the 15-day window. See STR procedure.

Step 6 — Onward action

• Tier step-up enforced where the structuring was evading a step-up threshold (R50k → L2; R100k → L3).
• Enhanced monitoring continues on the customer for at least 90 days post-STR.
• Where the structuring is sufficiently serious or repeats, the relationship is terminated. See termination playbook.

Playbook — PEP or FPPO identified

A customer, beneficial owner or family-member has been identified as a politically exposed person.

Step 1 — System detection and categorisation

Sumsub continuous screening and SNTNL adverse-media monitor raise PEP / FPPO / PIP designations against the customer base in real time, against FICA Schedules 3A, 3B and 3C. Cloudlog auto-opens a ticket (category "Compliance — PEP review") with the AI Co-Pilot's preliminary categorisation: foreign PEP, domestic PEP, FPPO, DPIP, or family-member / known close associate of one of the above. Position, country, term of office and any related-party links pre-populate from the source data.

Step 1a — Compliance Officer confirmation — the human step

1. Confirm the match is genuine (not a false positive on identifying details).
2. Validate the AI's categorisation against the schedule definitions.
3. Where the customer is JR-onboarded, the JR partner's Compliance Officer is notified per the co-sign protocol (see JR partnerships).

Step 2 — Risk treatment

Step 3 — EDD steps

1. Detailed information on the customer's occupation, employment history, current and past positions.
2. Reasonable measures to establish the source of wealth and the source of funds.
3. The customer's risk rating is elevated to high.
4. The customer is placed on enhanced ongoing monitoring.
5. Quarterly file refresh applies (every 3 months for high-risk).

Step 4 — Decision and documentation

1. The Compliance Officer documents the assessment and obtains senior management approval for foreign PEPs.
2. The decision is signed off and retained on the customer file for at least 5 years post-termination.

Step 5 — Ongoing

The Compliance Officer maintains awareness of the customer's status. Where adverse media or position changes occur, the file is refreshed and the rating reviewed.

Playbook — Adverse media event

Adverse media has surfaced involving a customer, beneficial owner or controlling person.

Step 1 — System detection and capture

SNTNL's adverse-media feed (continuous) and the weekly full-base sweep raise hits against named customers, beneficial owners and controlling persons. Cloudlog auto-creates a ticket (category "Customer — adverse media") with the source article(s), date, source credibility assessment from the AI Co-Pilot (established media vs blog vs social media), nature of the allegation classification, and a draft impact-on-residual-risk note.

Step 1a — Compliance Officer assessment — the human step

1. Validate the AI's source-credibility assessment.
2. Validate the allegation classification — financial crime, violence, organised crime, regulatory misconduct, fraud, corruption.
3. Determine whether the allegation, if true, would be material to the firm's residual risk on this customer.
4. For JR-onboarded customers, notify the JR partner's Compliance Officer per the co-sign protocol.

Step 2 — Risk re-rating

1. Update the customer's risk rating based on the adverse media. Default — elevate to high risk if the allegation is material.
2. Update Annexure A indicators on the customer file.

Step 3 — EDD if elevated

1. Refresh CDD if elevated to high risk.
2. Establish or re-verify source of funds and source of wealth.
3. Place the customer on the high-risk watch list.

Step 4 — Termination question

Where the allegation is sufficiently serious, or where the residual risk is unacceptable, the relationship is terminated. See termination playbook.

Step 5 — STR consideration

Adverse media in itself does not require an STR. But where the media reveals facts that, if true, would make a transaction suspicious, the STR test under section 29 is met and the STR playbook applies.

Playbook — Customer crosses the R50,000 threshold

A customer's lifetime exposure or monthly cumulative activity has reached R50,000.

Step 1 — System detection and automated step-up initiation

SNTNL monitors every transaction in real time against the R50,000 threshold at user level (cross-wallet aggregated). When the trigger fires — lifetime combined exposure reaches R50,000 OR current calendar-month transactions in/out reach R50,000 — three things happen automatically within seconds:

• Sumsub step-up flow is initiated for the customer's record.
• In-app notification served to the customer explaining the next verification step.
• Outbound transactions above the L1 cap (R50,000) are blocked at the platform level.

Step 2 — Customer completes L2 verification

The customer uploads proof of residential address (utility bill, bank statement, lease, or official correspondence not older than three months) and completes a source-of-funds declaration in the Sumsub flow. Sumsub processes the documents and updates the customer's tier to L2 on completion.

Step 3 — Day 8 — automatic full block

If the L2 verification has not been completed by the end of day 7 (the grace window), outbound transactions are blocked entirely on day 8. Inbound continues to function. The system serves an updated in-app notification. The block remains in place until the step-up is completed.

Step 4 — Hardship override — human exception only

The Compliance Officer can grant a hardship override on application. The override is recorded in Cloudlog with customer reference, reason, duration, and approval signature. The override is for the minimum required period and is reported at the next Board meeting.

Step 5 — Exception handling

Where the L2 verification documents are unusual, incomplete, or inconsistent with the customer's profile, Cloudlog auto-creates an EDD ticket routed to the Compliance Officer. Where the customer cannot or will not complete the verification, the cannot-verify playbook applies.

Cross-wallet aggregation — always-on

The R50,000 trigger applies at user / entity level. SNTNL links wallets belonging to the same user using KYC identifiers, device fingerprinting, IP clustering and behavioural patterns. Users cannot evade by spreading activity across wallets — the platform aggregates in real time. See cross-wallet aggregation.

Playbook — Customer crosses the R100,000 threshold

A customer's lifetime exposure or monthly cumulative activity has reached R100,000.

Step 1 — System detection and automated step-up initiation

SNTNL monitors every transaction against the R100,000 threshold at user level. When triggered — lifetime exposure or current calendar-month activity reaches R100,000 — Sumsub step-up flow opens automatically, in-app notification is served, and outbound transactions above L2 are capped.

Step 2 — Customer completes L3 verification

The customer completes the following in the Sumsub flow:

• Video identification interview — live agent or recorded-and-reviewed in Sumsub.
• Proof of source of funds — document evidence (salary advice, sale-of-asset documentation, business income evidence, inheritance documentation).
• For high-value transactions or potentially high-net-worth customers, proof of source of wealth.

Step 3 — Compliance Officer review — the human approval step

On L3 verification completion, Cloudlog auto-creates a sign-off ticket routed to the Compliance Officer. The Compliance Officer reviews the L3 verification file, the video ID outcome, the source-of-funds documentation, and the customer's risk profile. The first transaction at L3 — particularly if over R200,000 in a 7-day period — is reviewed and signed off before execution. The customer is placed on quarterly file refresh.

Step 4 — Day 8 — automatic block

If the L3 verification has not been completed by end of day 7, outbound transactions are blocked entirely on day 8. The customer is notified. The block lifts only on verification completion or Compliance Officer hardship override.

Step 5 — Enhanced ongoing monitoring — automated

All L3 customers are on the high-risk watch list automatically. SNTNL applies enhanced monitoring rules: every transaction reviewed by the AI Co-Pilot, behavioural baseline tightened, adverse media weekly sweep on this customer's name and identifiers. Quarterly file refresh prompts surface in Cloudlog as scheduled tickets to the Compliance Officer.

Key Individual escalation — assets above R1 million

Where a customer's lifetime exposure or assets under control exceed R1 million, the Compliance Officer notifies the Key Individual. The Key Individual is informed of any material event affecting that customer thereafter.

Playbook — Customer cannot be verified

A customer cannot or will not provide the required CDD information.

Step 1 — System detection and customer notification

Sumsub flags the inability to verify at the relevant verification step (identity document, liveness, proof of address, source of funds, or KYB documentation). Cloudlog auto-creates a ticket (category "Customer — verification failure") with the specific verification step that failed, the documents already on file, and the gap. The AI Co-Pilot drafts the customer notification using the firm's template — specific about what's required, operational rather than legal — and a reasonable response period.

Step 1a — Compliance Officer approval before sending

1. The Compliance Officer reviews the AI-drafted notification.
2. Sumsub re-opens the relevant verification step for the customer.
3. The customer receives the notification with the specific instruction.

Step 2 — If still no compliance

Under FICA, RainFin:

• May not establish a business relationship.
• May not conclude a single transaction.
• Must terminate any existing relationship.
• Must consider filing an STR.

Step 3 — Terminate

Use the termination playbook. Where the inability to verify is itself suspicious — for example, customer is evasive or provides false documents — the STR threshold is met and the STR playbook applies.

Step 4 — Tipping-off awareness

Where the termination is connected to an STR, the customer is not told the real reason. Standard termination language is used.

Playbook — Terminating a customer relationship

How RainFin ends a customer relationship. Special care where an STR is involved.

Step 1 — Cloudlog ticket — case of record

Termination starts with a Cloudlog ticket. Category depends on the underlying reason — "Customer — termination (standard)" for cases not connected to a regulatory matter; "Customer — termination (STR-linked)" or "Customer — termination (sanctions)" where the underlying reason engages tipping-off. The ticket is the case of record for everything that follows.

Step 2 — Decision and approval — human step

1. The Compliance Officer documents the reason for termination and the supporting evidence in Cloudlog.
2. Where the termination is connected to an STR or sanctions match, the Key Individual is notified and the ticket carries the tipping-off restriction flag.
3. Where the customer is JR-onboarded, the JR partner's Compliance Officer is notified per the co-sign protocol — see JR partnerships.
4. External counsel is engaged where the termination could give rise to a customer complaint or regulatory exposure.

Step 3 — Customer communication — AI-drafted, human-approved

The AI Co-Pilot drafts the termination notice using the appropriate template — see termination notice template. Where the termination is connected to an STR or sanctions match, the AI uses the standard wording that does not reveal the real reason. The Compliance Officer reviews and approves before the notice is sent.

Step 4 — Off-board — system-enforced

1. Customer is notified of the wallet closure date (typically 30 days from notice).
2. SNTNL applies a withdraw-only restriction — customer can only withdraw legitimate balance to a previously-verified destination.
3. Where the customer is sanctioned or subject to a section 34 directive, the freeze remains in place. The customer cannot withdraw.
4. On the closure date, the wallet is closed automatically. The customer file is marked accordingly in Sumsub.
5. If the customer is JR-onboarded, the JR partner is informed of the closure date.

Step 5 — Records — automated retention

The Cloudlog ticket and the Sumsub customer file are retained for at least 5 years from the date of termination per FIC Act section 23. The retention is system-enforced — records cannot be destroyed in this window.

Step 6 — STR consideration

If the underlying reason for termination is suspicion under section 29, an STR is filed in parallel. Filing an STR does not require RainFin to stop the wallet closure or the orderly off-boarding. See STR procedure.

Playbook — FIC section 27 information request

The FIC has asked for information about a specific person or relationship.

Step 1 — Verify the request

1. Open the goAML inbox. Confirm the request is from an authorised FIC representative.
2. Note the request reference number and the response deadline.
3. Read the request twice. Identify exactly what is being asked.

Step 2 — Identify records

1. Search RainFin records using the criteria in the request (name, ID number, registration number, account number, transaction reference).
2. Identify all relevant records — KYC, transactions, communications, STR filings, EDD outputs.
3. Note the date range, the customer scope, and any related records.

Step 3 — Prepare the response

1. Draft the response in writing, addressing each numbered request from the FIC.
2. Include annexures with full records — KYC files, transaction histories, screenshots, STR copies.
3. Compliance Officer signs off.
4. Engage external counsel before responding if the request touches matters under privilege, or if the request appears to be outside the FIC's section 27 power.

Step 4 — File

1. Respond via goAML or the channel specified in the request.
2. Confirm receipt of response by the FIC.
3. Retain the response and all annexures on the compliance file.

Penalty for non-response

Failure to respond is an offence under section 61A — up to 15 years' imprisonment or a fine of up to R100 million, plus administrative sanctions.

Playbook — FIC section 32 additional information request

The FIC has asked for additional information following a report.

Step 1 — Link to the original report

1. Identify the original report the s32 request relates to.
2. Pull the original file — the alert, the STR narrative, the goAML receipt, supporting evidence.

Step 2 — Identify the additional information

The FIC may ask for grounds for the suspicion, additional transactions related to the same customer, related customer relationships, or for any other information reasonably required for the FIC's functions.

Step 3 — Prepare and respond

Same procedure as a section 27 response. Compliance Officer signs off. Retain on file.

Playbook — FIC section 34 intervention directive

The FIC has directed RainFin to suspend a transaction or freeze an account.

Step 1 — Action the freeze immediately

1. Open a Cloudlog ticket. Category: Regulator — s34 — urgent. The ticket is the case of record for the freeze, every communication with the FIC, and every action taken until the directive expires or is converted.
2. Identify the affected customer and the impacted transactions.
3. Apply the freeze in SNTNL and on the wallet ledger.
4. Confirm the freeze is in place — verify no transactions can be processed during the directive period.
5. Time-stamp the freeze action.

Step 2 — Notify the Key Individual

Section 34 is a material event. The Key Individual is notified the same day.

Step 3 — External counsel

Engage external counsel for any communications back to the FIC beyond confirmation of the freeze, and for the customer-facing process if the customer becomes aware of the freeze.

Step 4 — Compliance with the directive period

1. The directive will specify a period — typically a number of days during which the freeze is in place.
2. Maintain the freeze for the full period.
3. Do not lift the freeze before the period expires unless the FIC issues a further directive.
4. The customer is not informed of the directive.

Step 5 — End of directive period

The FIC may extend, lift or convert the directive at the end of the initial period. Await further direction. Where the directive expires without extension, the freeze is lifted — subject to the Compliance Officer's discretion on residual risk.

Step 6 — Records and Board notification

The s34 event is recorded in the compliance event log. The Board is informed at the next meeting (or earlier where the event is material).

Playbook — FIC or FSCA inspection notice received

A regulator has given notice of an inspection or on-site review.

Step 1 — Acknowledge — Cloudlog opens, external counsel engaged

On receipt of an inspection notice from the FIC, FSCA, SARB or any other regulator, Cloudlog auto-creates a high-priority ticket (category "Regulator — inspection") routed to the Compliance Officer and Key Individual simultaneously. The ticket holds the notice itself, the scope, period in question, records sought, on-site date, and the SLA counter.

1. Acknowledge receipt in writing within 24 hours — AI Co-Pilot drafts the acknowledgement; Compliance Officer approves and sends.
2. Engage external counsel from the moment of acknowledgement.
3. Convene the inspection preparation team — Compliance Officer (lead), Key Individual, Head of Operations, external counsel.

Step 2 — Internal preparation

1. Convene a preparation team — Compliance Officer, Key Individual, Head of Operations, external counsel.
2. Identify the records the regulator will look at — KYC, transactions, STR filings, training records, vendor agreements, this programme.
3. Ensure every record is up to date and indexed.
4. Pre-test responses to anticipated questions.

Step 3 — On-site

• Designate a single point of contact for the regulators — the Compliance Officer.
• All requests for information are channelled through the Compliance Officer.
• Take contemporaneous notes of every interaction, every question, every commitment given.
• Where a request goes beyond the agreed scope, raise it respectfully with the lead inspector.
• Provide the records sought without delay.
• No off-the-record conversations. No commitments without external counsel review.

Step 4 — Post-inspection

1. Within 48 hours of the inspection, the team debriefs and documents what was inspected, what was asked, what was found.
2. Any follow-up requests from the regulator are addressed promptly.
3. Where the regulator issues findings or directives, external counsel advises on response.

Step 5 — Board notification

Any inspection is reported to the Board within 7 days. A full debrief follows the regulator's findings.

Playbook — Banking partner DD request

A banking partner has requested information for their annual periodic review or KYC refresh.

Step 1 — Acknowledge and clarify

1. Acknowledge the request promptly.
2. Clarify exactly what is required and the deadline.
3. Note that DD requests can be substantial — typically include the RMCP (in summary or redacted form), proof of operating address, financial statements, ownership disclosure, board composition, sanctions screening confirmation, and AML attestations.

Step 2 — Decide what to share

Use the redaction principle — share enough to satisfy the bank's DD obligations but not the full programme. See availability.

• Share — summary RMCP, top-level governance, vendor list, attestations.
• Do not share — detailed monitoring rules, internal thresholds, audit findings, specific customer information.
• Where the bank requires the full programme — share under an NDA reviewed by external counsel.

Step 3 — Compile and respond

Prepare a single response package. Confirm internally before sending. Submit via the bank's designated portal or secure email.

Step 4 — Follow-up

Bank may ask for further detail. Use the same redaction principle. Do not allow scope creep beyond what is necessary.

Step 5 — Record

Every banking partner DD response is recorded. Track when each banking partner's review cycle is due so we are not caught flat-footed (as happened with VALR's 2026 review).

Playbook — Sumsub outage

Sumsub is unavailable. Existing customers are unaffected; new onboarding and tier step-ups need a fallback.

Step 1 — Detection — automated

Sumsub uptime is monitored continuously. On material outage, Cloudlog auto-creates a high-priority ticket (category "Vendor — outage") and the Compliance Officer and Head of Operations are notified within 15 minutes via Slack and the daily brief. The Sumsub vendor performance dashboard (live evidence) updates with the incident.

Step 1a — Confirm scope and ETA

1. Contact Sumsub support — Tom Schoon or Anastasiia Popova — for outage scope and expected resolution time.
2. Determine which features are affected (ID verification, liveness, screening, ongoing monitoring) — the manual fallback plan depends on the scope.

Step 2 — Customer-facing

• New customer onboarding — paused. Customers attempting to onboard are shown a temporary maintenance message.
• Existing customers — may continue to transact within their current tier without disruption.
• Tier step-up flow — paused. Customers approaching a step-up are temporarily allowed to continue at their current tier with enhanced monitoring.

Step 3 — Manual fallback

1. Customers requiring a tier step-up during the outage are offered a manual KYC process by the Head of Operations.
2. Manual onboarding follows the Sumsub-equivalent checklist (see Annexure C).
3. Records of every manual onboarding or step-up are reconciled into Sumsub once service resumes.
4. The Compliance Officer signs off on every manual decision.

Step 4 — Resolution

1. Once Sumsub is back online, reconcile all manual onboardings into Sumsub.
2. Document the outage in the compliance event log — duration, customer impact, manual decisions made.
3. Vendor performance review — note the outage on the next quarterly Sumsub review.

Playbook — Ravencall (SNTNL) outage

SNTNL is unavailable. Transaction monitoring drops back to manual review.

Step 1 — Detection — automated

SNTNL's health monitor is continuous. On detection of material outage (alert ingestion failure, screening unavailable, or core monitoring degradation), Cloudlog auto-creates a high-priority ticket (category "Vendor — outage") and notifies the Compliance Officer and Head of Operations within 15 minutes via Slack. The vendor performance dashboard updates.

Step 1a — Confirm scope and ETA

1. Contact Ravencall support via info@ravencall.co.za or the Craven Buitendach direct channel.
2. Determine the scope — full outage, screening only, on-chain only, Travel Rule only — to apply the right manual fallback.

Step 2 — Transactional throttle

1. Transactions above R10,000 are held for manual review.
2. Manual review is performed by the Compliance Officer or Head of Operations using the wallet ledger directly.
3. Sanctions screening is performed manually against the FIC TFS list, OFAC and EU lists via the source list websites.
4. Travel Rule transfers are paused for the duration of the outage.

Step 3 — Records

• Every manual decision is recorded with reason and timestamp.
• Records are reconciled into SNTNL once service resumes.

Step 4 — Resolution

1. Confirm SNTNL is fully operational.
2. Reconcile manual records.
3. Document the outage in the compliance event log.
4. Review whether the outage exposed any customer to elevated risk during the period — if yes, refresh CDD for those customers.

Playbook — Unhosted wallet request

A customer requests a transfer to or from an unhosted (self-custodial) wallet.

Step 1 — System detection

SNTNL's on-chain scanner flags the destination or source wallet as unhosted (self-custodial) via on-chain analysis. The transaction is held pending source-of-control verification. Cloudlog auto-creates a ticket (category "Compliance — unhosted wallet"). AI Co-Pilot drafts the source-of-control attestation request to the customer.

Step 2 — Customer attestation

The customer submits a signed message or wallet-control proof through the RainFin app. SNTNL validates the signature against the wallet address.

Step 3 — Automated EDD checks

SNTNL runs:

• On-chain screening against OFAC, UN, and proprietary sanctions lists.
• Hop tracing — connection to darknet markets, mixers, ransomware payment addresses, or high-risk exchanges.
• Behavioural pattern analysis on the unhosted wallet's prior activity (where visible).

Findings populate the Cloudlog ticket.

Step 4 — Compliance Officer approval — the human step

The Compliance Officer reviews the wallet attestation, the on-chain analysis output, and the hop-trace findings. Approves or declines the transaction. Where the wallet history is suspicious or unverifiable, the transaction is declined and an STR is considered.

Step 3 — Compliance Officer sign-off

The Compliance Officer signs off on every unhosted wallet transaction. The decision is recorded on the customer file with the on-chain analysis output and the source-of-control attestation.

Step 4 — Enhanced ongoing monitoring

Following an unhosted wallet transaction, the customer is placed on enhanced monitoring. Subsequent transactions involving the unhosted wallet are reviewed individually.

Playbook — KYB high-risk decision

A KYB onboarding has been assessed as high risk. Compliance Risk Committee decides.

Step 1 — KYB completed in Sumsub

The KYB flow in Sumsub collects every document per Annexure C for the entity type. Beneficial ownership is established per the three-step process of elimination. Sanctions, PEP and adverse-media screening run automatically on every BO and authorised person identified. EDD documentation — source of funds, source of wealth, business model verification — is gathered. Cloudlog auto-creates a ticket (category "KYB — high risk review") on completion of the Sumsub flow where the customer scores as high risk.

Step 2 — Risk rating

Customer rated under section 5 using Annexure A. High risk on any one factor sets the overall rating. Document the rating with reasons.

Step 3 — Compliance Risk Committee

1. The Compliance Officer prepares a paper for the Compliance Risk Committee covering the customer, the BO chain, the assessed risk, the EDD findings, the controls proposed, and a recommendation.
2. The Committee — Key Individual (chair), Compliance Officer, Head of Operations — meets and decides. Decision is collective. No individual approves alone.
3. The decision is documented with reasons.

Step 4 — Conditions

Where the Committee accepts the customer, conditions are typically attached — quarterly file refresh, transaction caps, EDD on every transaction above a defined size, specific reporting to the Compliance Officer.

Step 5 — Ongoing

The customer is placed on the high-risk watch list. Quarterly review applies. Any material change triggers a return to the Committee.

Playbook — Employee suspicion

An employee suspects suspicious activity. What they do, what the firm does.

For the employee

1. Report it. To the Compliance Officer, in writing, without delay. Email or Slack DM. Cloudlog has a "Report a suspicion" form accessible to all staff that opens a ticket directly into the Compliance Officer's queue.
2. Do not discuss it. Do not tell the customer. Do not tell anyone else in the firm outside the compliance function. Do not discuss it in any informal channel. Tipping-off carries up to 15 years' imprisonment.
3. Document what you saw. Date, time, the transaction or interaction, what triggered the suspicion. Facts only — no speculation.
4. Continue to do your job. Filing a report does not require the firm to stop a transaction.

For the Compliance Officer

1. The Cloudlog ticket from the employee form auto-routes to the Compliance Officer's queue with the employee's submission attached.
2. AI Co-Pilot pulls the relevant customer / transaction data from SNTNL and Sumsub and pre-populates the case.
3. Apply the section 29 threshold — does the test apply?
4. If yes — STR filing via the STR playbook.
5. If no — record the reasons-not-to-file in Cloudlog.
6. Provide feedback to the employee — without disclosing whether or how the firm acted on the report (tipping-off applies internally too).

Legal protection

No legal action — criminal or civil — can be instituted against an employee who complies in good faith with a reporting obligation. The identity of the reporter is protected.

Whistleblower channel

Where the employee's concern is about another employee, a contractor, or a member of management — the firm's whistleblower channel applies (RF-HR-WB-001). Reports through the whistleblower channel are confidential.

Thresholds at a glance

Every threshold that fires a control. Memorise these.

Deadlines at a glance

Every regulatory deadline that applies to RainFin's compliance function.

Contacts directory

Who to call, who to email, when. Keep this open during any urgent matter.

Internal — RainFin

External — CAEP Partners (compliance advisory)

Vendors

Regulators

Partners

Acronyms

Every acronym used in this programme.

Who decides what

The decision authority matrix.

STR narrative template

The structure of an STR narrative. SNTNL generates the draft; Compliance Officer edits and signs off.

Structure

The STR narrative is filed via goAML with the following structure. SNTNL produces the AI draft; the Compliance Officer edits to ensure facts and tone.

1. Customer information

• Full legal name; ID or passport number; date of birth; address.
• Registered name and registration number (for legal persons).
• Beneficial owners and their identification details.
• Account or wallet identifiers held by RainFin.
• Customer's KYC tier and current risk rating.

2. Transaction information

• Transaction date(s) and time(s).
• Amount and currency.
• Counterparty information (where known).
• Transaction type (deposit, withdrawal, crypto transfer, internal transfer).
• Wallet addresses involved (on-chain).
• The rule(s) in SNTNL that fired the alert.

3. Grounds for suspicion

This is the substantive part. Set out, in plain English:

• The facts known to RainFin.
• Why those facts give rise to a suspicion under section 29.
• The specific section 29 element that applies (proceeds of unlawful activity; evasion of reporting; no apparent business or lawful purpose; higher-risk person; tax evasion relevance; terrorist or related activity).
• Reference to behavioural baseline deviation, jurisdictional risk, source-of-funds inconsistency, sanctions or PEP designation, on-chain risk, structuring pattern, adverse media — whichever apply.

4. Actions taken

• Whether the transaction was completed, declined, or held.
• Whether the customer relationship is being terminated.
• Customer not informed (tipping-off).
• Internal escalation to the Key Individual (where material).

5. Supporting evidence

• KYC file (referenced; not copied).
• Transaction record.
• SNTNL alert detail.
• On-chain analysis output (where relevant).
• Adverse media articles (where relevant).
• Sanctions screening output.

Drafting tone

Factual, neutral, complete. No speculation beyond what the facts support. No accusatory language. The Compliance Officer is reporting facts and the suspicion they give rise to — not making a legal finding.

Customer decline letter template

For customers who cannot be onboarded.

Template — onboarding decline (no STR connection)

Template — onboarding decline (cannot verify identity)

Relationship termination template

For terminating an existing customer relationship.

Template — standard termination (no STR connection)

Template — termination where customer cannot be re-verified

EDD documentation template

The structure of an EDD file. Every high-risk customer has one.

EDD file structure

1. Customer overview. Full identification details, KYC level, current risk rating, reason for EDD (PEP, sanctions, complex structure, adverse media, large transaction, prior conviction).
2. Beneficial ownership detail. For juristic persons — full BO chain, percentage ownership, identification of each BO, screening results.
3. Source of funds verification. Documents obtained — salary advice, sale documents, business income evidence, inheritance documentation. Verified against the customer's stated source.
4. Source of wealth verification. Where high-value transactions or potentially high-net-worth — total wealth, accumulation history, current composition.
5. PEP / sanctions / adverse media analysis. Screening results. Compliance Officer's assessment of each match.
6. Risk indicators applied. Annexure A indicators that apply to this customer.
7. Compliance Officer assessment. Reasoned conclusion on whether the customer is acceptable. For high-risk customers — senior management approval. For prior conviction customers — Compliance Risk Committee decision.
8. Conditions. Any conditions imposed — transaction caps, EDD on each transaction over a size, quarterly file refresh, specific reporting.
9. Sign-off. Compliance Officer signature, date. Senior management sign-off where required.
10. Ongoing monitoring plan. Frequency of file refresh, specific triggers for re-assessment.

Internal escalation template

For escalating a compliance matter from Operations to Compliance Officer, or from Compliance Officer to Key Individual.

Escalation note structure

1. What. A one-sentence description of the matter.
2. When. Date and time of the triggering event.
3. Customer or transaction reference. The specific identifier so the escalation can be located.
4. Why escalating. The specific threshold or criterion that requires the next level of attention.
5. Action taken so far. Anything done at this level — alert reviewed, customer placed on hold, manual KYC initiated.
6. Action sought. What you want from the next level — decision, sign-off, awareness, external counsel engagement.
7. Deadline. When this needs to be resolved.

Channel

• Operations → Compliance Officer. Slack DM or email; same-day acknowledgement required.
• Compliance Officer → Key Individual. Email; same-day acknowledgement required for material matters.
• Compliance Officer → Compliance Risk Committee. Scheduled meeting or out-of-cycle convening.
• Key Individual → Board. Next scheduled meeting; same-week for material events.

Tipping-off awareness

Where the escalation is connected to an STR or sanctions match, the escalation itself is confidential. Use the secure channel only. Do not discuss in any informal channel.

Customer communications templates

Standard wording for common customer-facing situations.

Step-up notification (L1 → L2)

Step-up notification (L2 → L3)

Outbound transaction blocked

EDD request

RainFin Wallet operations

Day-to-day operational guidance for the RainFin direct retail wallet.

What it is

The RainFin Wallet is the retail wallet through which South African residents onboard onto, hold, transfer and convert crypto assets and stable money under RainFin's CASP licence.

Onboarding

• Sumsub flow at L1 entry.
• Compliance scope — full CDD; sanctions, PEP and adverse media screening.
• Step-up to L2 at R50,000; to L3 at R100,000.

Key controls

• Cross-wallet aggregation across all RainFin wallets linked to the customer.
• SNTNL real-time monitoring of every transaction.
• Travel Rule on outbound crypto transfers above the FIC Directive 9 threshold.
• Sanctions screening at onboarding, on every transaction, and on every TFS list update.
• On-chain scanning of every wallet address involved in a deposit or withdrawal.

Operational specifics

• Customer support — first-line via the support channel. Compliance queries routed to Operations for triage, then to the Compliance Officer where regulatory.
• Withdrawal lifecycle — the nine-step process under Transactional Risk.
• Withdrawal Policy — full operational detail at BMAWAASWPPRR001.
• SARS CARF reporting — TIN collected at onboarding; first reporting cycle from 1 March 2027.

Risk profile

Medium-high inherent risk (see Product risk). Drivers — crypto velocity, pseudonymity, retail customer base, on-ramp / off-ramp risk, potential for structuring.

AVBOB Wallet operations

Day-to-day operational guidance for the AVBOB Wallet under the juristic representative arrangement.

What it is

The AVBOB Wallet is offered through RainFin under a juristic representative arrangement with AVBOB. AVBOB customers access a regulated digital wallet for which RainFin is the licensed CASP and FSP.

Onboarding flow

• AVBOB customer initiates wallet creation through AVBOB's interface.
• Sumsub onboarding flow at L1.
• AVBOB FAQs document (v1.3) sets out customer-facing expectations.
• KYC costs charged back to AVBOB per the agreed pricing.

Key controls — same as RainFin Wallet

• Three-tier KYC with the same R50,000 and R100,000 thresholds.
• Cross-wallet aggregation applies across AVBOB Wallet and any other RainFin wallet held by the same customer.
• SNTNL monitoring, sanctions screening, Travel Rule — same as RainFin Wallet.

Compliance interface with AVBOB

• AVBOB Compliance reviews the RMCP periodically — most recently 14 May 2026.
• AVBOB Compliance contact — Joanne van Greunen (forwarding) and the Compliance team behind her (Victor's review).
• Material RMCP amendments are flagged to AVBOB Compliance.
• Issues identified by AVBOB Compliance are addressed in the next RMCP version.

Specific notes

• Premium collection. The use of AVBOB Wallet to settle insurance premiums was flagged on 26 January 2026 as a perimeter question (Cat I LT/ST insurance licensing). External counsel is to be engaged before any expansion of this use case.
• AVBOB Living Savings vs AVBOB Wallet naming — see the AVBOB FAQs for the current branding.

Risk profile

Medium inherent risk (mitigated by AVBOB's customer base profile and the closed-loop top-up flow). See Product risk.

eZar stable money operations

Day-to-day operational guidance for the eZar stable money product.

What it is

eZar is a ZAR-referenced yield-bearing stable money product. The yield is referenced to the Ninety One Money Market rate on a T-1 basis.

Key controls

• Tiering applies as per the standard three-tier framework.
• Yield accrual is independent of tier.
• Transactions out of eZar balances above the L2 and L3 thresholds require the corresponding verification to have been completed.
• SNTNL monitors eZar transactions with the same rule set as crypto-asset transfers.
• SARS CARF reporting applies to eZar holdings from 1 March 2027.

Operational specifics

• Yield calculation reconciled daily against Ninety One's published rate.
• Minting validation per platform rule 3 applies — every deposit verified as minted, every withdrawal reconciled before execution.

Risk profile

Medium-high inherent risk. Drivers — yield draws retail capital; SARS CARF reporting; cross-border perimeter sensitivity.

Tokenisation operations

Day-to-day operational guidance for the tokenisation of real-world assets.

What it is

RainFin designs and issues tokens representing real-world financial or commercial value, for institutional and qualifying-retail customers.

Onboarding

• Tokenisation customers typically enter at L2 or L3 from the outset, given the customer profile and transaction size.
• KYB-intensive onboarding — full document checklist per Annexure C.
• Specific risk assessment per token per new product process.

Key controls

• Securities perimeter analysis — every tokenised asset is assessed for FAIS, FSCA and JSE implications before issuance.
• Custody and settlement finality — documented per token.
• Token-holder CDD applies as for any RainFin customer.
• Counterparty CASP and Travel Rule apply where tokens are transferred to other CASPs.

Risk profile

High inherent risk. Drivers — securities perimeter risk, custody, KYB-intensive customer base. See Product risk.

Day 1 at RainFin Compliance

For anyone new joining the compliance or operations function. Your first day, in order.

Before you start

• You will have been screened for competence and integrity before your appointment.
• You will have been screened against the FIC's Targeted Financial Sanctions list.
• If you handle finance, you will also have completed credit screening.

Day 1 — induction

1. Read this programme. Start with Welcome, then read the About RainFin and Governance pages. Don't try to read everything — get a feel for the structure and where things live.
2. Read the Tipping-off rule. This is the one you must internalise from day 1. Read it now.
3. Sign the declaration of receipt and understanding. Confirms you've read this programme and accept your responsibilities.
4. Account access. Sumsub, SNTNL, goAML (where you need it for your role), Slack monitoring channel, RainFin shared drive.
5. Meet your colleagues. Meet the Compliance Officer, Head of Operations and Key Individual — current names and contact details in the Contacts directory.
6. Walk through the morning routine. Read the Daily routine page — this is what you'll do every morning.

Things to bookmark on day 1

• Thresholds at a glance — memorise R49,999, R50,000, R100,000, R19,999.99.
• Deadlines — STR 15 days, CTR 3 days, TPR 5 days, IFTR 3 business days.
• Contacts directory.
• Daily routine.

Don't try to learn it all today

You don't need to know every page of this programme by the end of week 1. You need to know where to find things, who to ask, and the few rules that apply absolutely from the moment you start (tipping-off, sanctions match, anonymous customer prohibition, your duty to report).

Week 1 — getting started

By the end of your first week, you should know your way around.

Read these pages

• The three KYC tiers — this is the heart of how we onboard customers.
• Natural persons and KYB — what we collect.
• Sanctions screening — the lists we screen against.
• PEP screening — the terminology that matters.
• Reporting — what we file and when.
• Eight platform rules — how SNTNL operates.

Shadow Operations

• Sit with the team for one morning routine.
• Watch how a Sumsub onboarding decision is made.
• Watch how an SNTNL alert is reviewed.
• Watch how a section 27 request is responded to (if one comes in).

Complete the FICA training

Within 30 days of appointment you must complete the FICA training. Start it in week 1 — the Compliance Officer will set you up with Masthead's online course.

Identify gaps

Write down anything in this programme that you don't understand. Ask the Compliance Officer at the end of the week. There will be things — this is normal.

Month 1 — settling in

By the end of your first month, you should be operationally capable.

FICA training complete

Required by section 43. Completion is logged in the training register.

You're doing the work

By end of month 1 you should be able to:

• Run the morning routine end to end.
• Review a medium-risk SNTNL alert and either resolve it or escalate.
• Review a Sumsub onboarding decision.
• Identify a sanctions match and follow the playbook.
• Identify an STR scenario and bring it to the Compliance Officer.
• Respond to a routine banking partner DD request (with Compliance Officer sign-off).
• Update a customer file with EDD documentation.

One-month review

You and the Compliance Officer have a one-month review. Feedback both ways. Identify training gaps. Adjust if anything is not working.

Reading list for month 2

• Document checklists — for the entity types you will encounter.
• Risk indicators — go deeper.
• Read at least three playbooks.

Annual refresher

Every employee re-trains annually. This is the structure.

Why an annual refresher

FICA section 43 requires ongoing training. The regulatory landscape changes — new directives, new typologies, new lists. The firm's own controls change — new products, new vendors, new SNTNL rules. The annual refresher keeps everyone current.

What the refresher covers

• The customer due diligence process — any changes in the past year.
• Sanctions, PEP and adverse media screening — any new lists or processes.
• Recognition of suspicious activity — typologies relevant to our business.
• The duty to report — and the tipping-off prohibition.
• The use of Sumsub and SNTNL — any new features or rules.
• Role-specific deep dives for Operations and Compliance.
• Material changes to this programme.

Format

• External — Masthead's online FICA course (1–2 hours).
• Internal — Compliance Officer-led session on material changes since last year.
• Assessment — written or verbal, confirming retention.

Logging

Attendance and assessment outcomes are logged in the training register. The Compliance Officer reports annual training completion to the Key Individual and the Board.

FIC inspection preparation

How RainFin prepares for and responds to a FIC inspection.

What the FIC inspects

Under section 45 of the FIC Act, authorised representatives of the FIC may inspect RainFin's records, premises and systems for the purpose of monitoring compliance. The scope of inspection includes:

• Customer due diligence — KYC and KYB files, EDD outcomes, sanctions screening records.
• Reporting — STR, CTR, TPR, IFTR filings and the reasons not to file.
• Records — completeness, retention, accessibility.
• Training — register, content, attendance.
• Employee screening — pre-employment and ongoing.
• This programme — content, approval, implementation.
• Governance — board oversight, escalation, conflicts management.
• Outsourcing — PCC 44A compliance for Sumsub and Ravencall.

Always-ready stance

The firm operates on the basis that an inspection could begin at any time. Records are kept current. The programme is reviewed annually. Training is logged. The vendor register is kept up to date.

Notice received — see the inspection playbook

The detailed steps from notice receipt to debrief are in the inspection notice playbook.

Records location

FSCA inspection preparation

How RainFin prepares for and responds to an FSCA inspection.

What the FSCA inspects

The FSCA may inspect under FAIS Act and FSR Act powers. Scope:

• Fit and proper of the Key Individual and representatives.
• Conduct compliance — fair customer treatment, complaints handling, advertising, advice records.
• Compliance officer's role and function.
• Operational ability — including this programme as part of the firm's governance and risk management framework.
• Compliance with the FAIS General Code of Conduct.
• CASP-specific conditions of licence.

Approach

Same as FIC inspection — always-ready stance, single point of contact (Compliance Officer), external counsel engaged from notice receipt, contemporaneous notes of every interaction.

Cross-regulator coordination

An FSCA inspection may run in parallel with FIC interest. Each regulator is treated independently — the Compliance Officer manages each separately and does not allow scope to bleed across.

Banking partner due diligence

Operating with banks that hold RainFin's bank accounts. Their DD obligations on us.

Why this matters

Banking partners (the institutions that hold RainFin's bank accounts and process payments) are themselves accountable institutions. They run periodic DD on RainFin to satisfy their own AML obligations. The reviews are typically annual.

Periodic review process

• Bank sends a DD request listing the documents and information required.
• RainFin responds with the package within the bank's deadline.
• Bank reviews and either confirms continued service or asks for more.

What banks typically ask for

• Current proof of operating address.
• Latest audited financial statements.
• Beneficial ownership disclosure.
• Board and senior management composition.
• This programme — summary or redacted form (see availability).
• Confirmation of sanctions screening practice.
• STR / CTR / IFTR filing posture (numbers, not contents).
• Vendor list.
• Compliance Officer attestation.
• Confirmation of fit-and-proper status of Key Individual.

Playbook

Full procedure in the banking partner DD playbook.

Tracking

Each banking partner's review cycle is tracked. VALR's review cycle is January (their 2026 review caught the firm flat-footed; this is a calendar action item).

AVBOB Compliance interactions

AVBOB is RainFin's juristic representative partner for the AVBOB Wallet. Their compliance team reviews our RMCP.

The relationship

RainFin is the licensed FSP and CASP. AVBOB operates as a juristic representative under RainFin's licence for the AVBOB Wallet product. AVBOB Compliance has a legitimate interest in reviewing RainFin's RMCP and the controls applied to AVBOB Wallet customers.

What AVBOB Compliance reviews

• The programme itself — current version.
• CDD applied to AVBOB Wallet customers.
• Sanctions and PEP screening.
• Reporting (STR, CTR, IFTR) posture.
• Material changes to controls.

14 May 2026 review

Victor at AVBOB Compliance provided a substantive review of the (then) signed-off RMCP. Seven specific defects identified and two broader concerns. RainFin's response was prepared and AVBOB's findings are addressed in v2026.1 (see the change log).

Engagement protocol

• AVBOB Compliance correspondence is treated as material — the Compliance Officer reviews and responds within 5 business days.
• Findings are taken at face value where they are technically correct.
• RainFin remediates and re-engages.
• The Key Individual is informed of substantive AVBOB Compliance reviews.
• External counsel is engaged where findings could trigger licensing or perimeter concerns.

AVBOB transition to FAIS licence holder

AVBOB is transitioning from juristic representative to FAIS licence holder in its own right. This transition is a defined workstream — see the Phase 1B and 2 scope. Material changes to RainFin's controls may be required as part of the transition.

Counterparty CASP due diligence

DD on the CASPs we transact with — for the Travel Rule and beyond.

Why we do CASP DD

Under FIC Directive 9 of 2024 (Travel Rule), before transmitting originator and beneficiary information for a qualifying crypto-asset transfer, RainFin must perform due diligence on the counterparty CASP. This satisfies FATF Recommendation 16 and section 26A of the FIC Act.

The DD elements

• Identification of the counterparty CASP — name, registration, regulatory status.
• Assessment of the counterparty's ability to protect the confidentiality of information transmitted.
• Assessment of whether the counterparty is identified pursuant to a UNSC resolution.
• Assessment of the counterparty's home jurisdiction against FATF lists.
• Where the counterparty is in a high-risk jurisdiction, enhanced scrutiny.

Maintaining the list

RainFin maintains a list of approved counterparty CASPs in SNTNL. Travel Rule transmission to an approved counterparty is automated. Transmission to a new counterparty triggers DD before the first transfer.

Refusal to comply

Where a counterparty cannot or will not provide the Travel Rule information required, the Compliance Officer determines whether to proceed (with a documented rationale), to delay the transaction, or to file a section 29 report. Where the counterparty has a pattern of non-compliance, RainFin removes them from the approved list.

RainFin's own KYB pack — what we share when DD'd

The document set we maintain ready for when a banking partner, auditor, regulator or counterparty performs due diligence on RainFin.

The standard external DD ask

The question set we work from is the one our auditor Forvis Mazars (Wiehann Olivier) uses, which is materially identical to what banking partners (VALR, Absa) and counterparty CASPs ask. Any external counterparty performing DD on RainFin will ask for some subset of:

Entity-level documents

• Certification of Incorporation (CoR14.3 — modern equivalent of CM1).
• Memorandum of Incorporation (MOI — modern equivalent of CM2), including any forms of amending company information.
• Recent letterhead or proof of address.
• Proof of operating address (if different from registered address).
• Key figures from latest management accounts — revenue, net profit/loss, employee headcount, net asset value.
• Tax clearance certificate.
• Most up-to-date group organogram showing entities, ownership percentages and ultimate beneficial owners.
• Group structure description.

Person exercising executive control (the Key Individual)

• Full legal name.
• Certified copy of identity document or valid passport.
• Country of citizenship / nationality with proof of address (utility bill or equivalent).
• Contact details.

Each person authorised to establish a relationship on behalf of RainFin

Same as the executive-control set above. The Key Individual is currently the sole authorised person; the signed mandate to the auditor / banking partner records this.

Each director

Same as the executive-control set above, unless there is a signed mandate or declaration authorising the CEO / MD to act alone (in which case only the CEO / MD information is required).

The current live KYB pack (RainFin GP)

The following documents make up the most recent KYB pack shared externally (March 2026, for the ForvisMazars KYC of RainFin GP):

The pack lives in the Finance Manager's RainFin finance folder. The Head of Operations has access; the Compliance Officer has access. Anyone needing the pack for a banking partner DD, auditor KYC or counterparty CASP review requests it from the Finance Manager.

The redacted version

For counterparties whose DD process does not warrant the full pack — for example a counterparty CASP doing initial Travel Rule due diligence — the Finance Manager and the Compliance Officer maintain a redacted version with the management accounts removed and the Key Individual's personal identification redacted. The redacted version is shared under NDA only.

Refresh cadence

• Annual — full refresh of the pack each January. Management report, organogram, address proofs all updated.
• On any director or shareholder change — pack updated within five business days; the Section 43B(4) notification to the FIC runs in parallel.
• On any change of registered or operating address — pack updated within five business days; banking partners notified.
• Before every banking partner annual review cycle — VALR is January, Absa is the trust account review; pack refreshed in advance.
• Before every audit cycle — pack refreshed in advance of the auditor's KYC walk-through.

Recent uses of the pack

• 3 March 2026 — Forvis Mazars KYC of RainFin GP (Wiehann Olivier and Tasneem Ally). Full pack supplied.
• 29 January 2026 — VALR Annual Periodic Review. Full pack except proof of address for the Key Individual and Hannes (subsequently completed).
• 17 April 2026 — Fedgroup onboarding documents (Ryan Shub). Pack shared in support of the invoice flow.

Where this connects to the rest of the programme

• Banking partner DD playbook — the operational procedure for responding to a bank's DD request, drawing on this pack.
• FIC inspection preparation — the FIC will ask to see equivalent information about the firm.
• Outsourcing — Sumsub and Ravencall — the same pack supports Sumsub and Ravencall vendor due diligence on RainFin where they need to verify the customer of their service.
• Governance — roles — the pack reflects the live director and KI / CO position as recorded in Section 3.

Incident response — Cloudlog

Cloudlog is the firm's incident management and case-of-record system. Every high-risk compliance event opens a Cloudlog ticket.

What Cloudlog is

Cloudlog is the BMA-group incident management platform. It centralises ticketing, evidence collection, investigation history, AI-assisted findings, and reviewer-approval workflows. For RainFin it functions as the system of record for compliance and risk incidents — the case-management layer that sits above SNTNL (the detection layer) and Sumsub (the identity layer).

What triggers a Cloudlog ticket

Medium-risk SNTNL alerts stay in SNTNL unless escalated by Operations. Low-risk alerts auto-resolve in SNTNL.

What a Cloudlog ticket contains

• The triggering event — SNTNL alert ID, FIC reference, banking partner reference, etc.
• The rule fired (for SNTNL alerts) and the composite risk score.
• The customer reference. Tipping-off sensitive matters: where the case is STR-relevant, the customer's identifying detail is held in a Compliance-only field, not in the ticket title or visible body.
• Evidence chain — system logs (CloudGate, HTTP traces, workflow runs, scheduler logs, database records), the SNTNL alert detail, the on-chain analysis output where relevant, the customer file extract.
• The AI-drafted findings summary and suggested root cause — editable by the Operations analyst and the Compliance Officer.
• The reviewer-approval record — Compliance Officer or designated reviewer signs off before closure.
• The regulatory filing reference where applicable — STR / CTR / IFTR / TPR identifier from goAML.
• The final decision and the rationale.

The SNTNL to Cloudlog handoff

1. SNTNL raises a high-risk alert. The composite risk score and the rule fired are captured.
2. The integration auto-opens a Cloudlog ticket. The ticket inherits the SNTNL alert ID, the rule context and the customer reference (per the tipping-off treatment in the previous section).
3. The Cloudlog ticket is routed to the Compliance Officer's queue. The Head of Operations sees the ticket in the supervisor view.
4. The Operations analyst (first line) gathers further evidence. The AI-drafted findings start to compose as evidence accumulates.
5. The Compliance Officer reviews. Where the threshold is met, the relevant report is filed (STR via goAML, TPR via goAML, etc. — see the Reporting section).
6. The reviewer approval is recorded on the ticket. The ticket is closed only when findings are approved.
7. The Cloudlog ticket and its evidence chain are retained for at least five years under FIC Act section 23.

The AI-drafted findings workflow

Cloudlog generates a draft summary of the incident and proposes a root cause as evidence accumulates on the ticket. The draft is editable. No ticket can be closed without a human reviewer (Compliance Officer or designated approver) editing or accepting the AI-drafted findings. This pattern — AI-assisted drafting with mandatory human approval before record creation — is what regulators increasingly expect for AI-generated content that becomes part of an evidence chain.

How Cloudlog connects to the rest of the programme

• Transactional Risk — eight platform rules — every high-risk alert under rules 1–8 opens a Cloudlog ticket.
• Sanctions match playbook — Step 3b records a Cloudlog ticket as the first action.
• STR triggered playbook — the Cloudlog ticket is the case-of-record holding the SNTNL evidence and the draft STR narrative.
• Section 34 directive playbook — the Cloudlog ticket records the freeze action and the audit trail of every subsequent communication with the FIC.
• Banking partner DD playbook — every banking partner request opens a Cloudlog ticket so the response is traceable.
• Records — Cloudlog tickets feed into the five-year retention obligation under section 23.

Open operational items

• SNTNL to Cloudlog integration — the technical integration between Ravencall's SNTNL and Cloudlog needs to be built. The Head of Operations is the operational owner; Niel Olivier (Cloudlog) and the Ravencall team are the technical counterparts.
• Cloudlog versus Jira — the dev work for the integration runs in Jira; the incidents themselves live in Cloudlog. The boundary needs to be documented so an inspector can trace from a customer complaint through to the underlying engineering ticket.
• AVBOB customer visibility — under the juristic representative arrangement, AVBOB customers should not see RainFin's internal compliance tickets. Niel can configure cross-board copying so customer-raised tickets appear on the internal board without granting reverse access. Confirm the default is set correctly.
• Slack notification configuration — high-risk tickets should mirror to the existing compliance Slack channel for visibility; no decisions or approvals occur in Slack.
• Stasha's follow-up ops session — pending; will firm up tenant model, watcher / group assignment, and remaining feature gaps.

Outsourcing disclosure (PCC 44A)

Cloudlog is operated by the BMA group and provided to RainFin under the broader BMA technology arrangement. Like Sumsub and Ravencall, the operational performance is outsourced; the regulatory obligation (to keep records under FIC Act section 22A and section 23, to maintain the integrity of the compliance evidence chain) remains with RainFin. The vendor register (Annexure G) records Cloudlog with its own PCC 44A disclosure: scope, due diligence performed, performance review cadence, exit and manual fallback.

Manual fallback if Cloudlog is unavailable

If Cloudlog is unavailable, the Compliance Officer maintains a temporary case log in a secure RainFin shared drive folder. Each case opened during the outage is recorded with the same minimum data set (triggering event, evidence chain, decision, reviewer approval). Records are reconciled into Cloudlog when service resumes. Cloudlog's own audit trail records the period of unavailability.

JR partnerships and co-signing protocol

How RainFin operates as the licensed FSP and CASP for customers onboarded through a Juristic Representative partner — and how regulatory reports on those customers are co-signed.

What a JR partner is

A Juristic Representative is an entity authorised to operate under RainFin's FSP licence to provide specific financial services to that entity's customers. RainFin retains the licence and the regulatory accountability. The JR partner provides the customer relationship and the operational front-end. Customers are technically RainFin's customers under the licence; the JR partner is the operational counterparty.

Current JR partner — AVBOB, for the AVBOB Wallet product under the RainFin / AVBOB Juristic Representative Agreement v1.0 dated 12 November 2025. AVBOB is transitioning toward its own FAIS licence; until that transition completes, AVBOB operates under RainFin's licence. Other partners may be added under the same model.

The co-signing protocol

When a regulatory report is being prepared on a customer onboarded through a JR partner:

1. System identifies the JR flag. The customer record in Sumsub and SNTNL carries a JR flag identifying the partner who onboarded them. When SNTNL opens a Cloudlog ticket for a regulatory event, the JR flag is read automatically.
2. Cloudlog auto-routes the co-sign request. For JR-onboarded customers, Cloudlog generates a co-sign request to the JR partner's named Compliance Officer (for AVBOB: the current AVBOB Compliance officer — Joanne van Greunen or Victor, or their successors, as recorded in the JR Agreement Annexure). The request goes via Cloudlog's secure cross-tenant channel; not via email or Slack.
3. JR Compliance Officer reviews the AI-drafted report in Cloudlog. They can see the regulatory report summary, the customer reference, and the AI-drafted narrative. They cannot see RainFin's internal SNTNL alert detail beyond what the report itself covers.
4. JR Compliance Officer signs off. Their co-sign is recorded against the Cloudlog ticket with timestamp.
5. RainFin's Compliance Officer files the regulatory report via goAML with both signatures appearing on the submission cover page. RainFin remains the named accountable institution under the FIC Act; the JR co-sign is an internal-governance control that strengthens the audit trail.

If the JR partner does not co-sign in time

The regulatory obligation to file the report is RainFin's. The JR co-sign is a control, not a precondition. If the JR partner's Compliance Officer does not co-sign within the defined window — 48 hours for STR (which has a 15-day filing deadline), 24 hours for TPR (5-day deadline), or whatever shorter window applies — RainFin files on the basis that the JR has been notified and proceeds. The Cloudlog ticket records the notification, the absence of co-sign, and the reason for proceeding. The matter is then raised with the JR partner under the JR Agreement governance.

Tipping-off discipline

Section 29(2A) prohibits disclosure of the fact or contents of an STR or related filing to anyone, except as permitted by the Act. The co-sign disclosure is narrow and permitted under the "scope of powers and duties under legislation" exception — the JR partner's Compliance Officer is part of the operational compliance function for that customer base under the JR arrangement.

• The co-sign request goes only to the JR partner's named Compliance Officer.
• Not to JR business, customer support, operations or any other staff at the JR partner.
• Cloudlog enforces this via the cross-tenant channel — the request is invisible outside the named compliance role at the partner.
• The customer is not informed under any circumstance.
• Where the JR partner's Compliance Officer needs to escalate internally within their organisation, they do so under their own tipping-off discipline — RainFin documents the disclosure to the JR; the JR documents their own internal handling.

Operational details by JR partner

AVBOB Wallet

JR: AVBOB Financial Services and the AVBOB Mutual Assurance Society. JR Agreement: RainFin / AVBOB Juristic Representative Agreement v1.0, 12 November 2025. AVBOB's named Compliance Officer is recorded in the Annexure to the JR Agreement and in the Contacts directory as the current operational counterpart. Co-sign requests on AVBOB-onboarded customers route to that named officer. AVBOB Compliance has previously conducted a substantive review of RainFin's RMCP (14 May 2026 — Victor's findings); the co-sign protocol formalises this same governance discipline at the per-report level.

Future-state note: AVBOB is transitioning from JR to FAIS licence holder. Once that transition completes, AVBOB takes primary accountable-institution status for AVBOB Wallet customers. The co-sign protocol then becomes a hand-over protocol — RainFin's reports on those customers transition to AVBOB's own goAML filings. The transition timing is governed by the JR Agreement Annexure and FSCA's approval of AVBOB's CASP licence application.

Future JR partners

For any new JR partner, the co-sign protocol forms a standard clause of the JR Agreement template. The JR's named Compliance Officer is recorded in the agreement's annexure and the Contacts directory. Cloudlog cross-tenant channels are provisioned on partner onboarding.

How this connects to the rest of the programme

• Reporting — every reporting procedure includes the JR co-sign step where the customer is JR-onboarded.
• Sanctions match playbook — co-sign on the TPR or STR that follows a confirmed sanctions match.
• STR triggered playbook — co-sign before goAML filing.
• Incident response — Cloudlog — the technical mechanism for the co-sign routing and recording.
• AVBOB Compliance interactions — the broader operational interface with AVBOB Compliance.

Live evidence

Real-time system output for every material control in the programme. Inspection-ready proof, one click from the description.

Available live reports

Coming next

Additional live evidence pages to be wired in from SNTNL, Sumsub, Cloudlog and goAML. The proposed inventory:

• TFS sanctions screening run — last screen against UNSC, OFAC, EU, HM Treasury, FIC TFS. Match count, false-positive decisions, true positives (frozen if any).
• STR filings register — last 30 days of section 29 reports, goAML reference numbers, status.
• CTR filings register — last 30 days of section 28 reports.
• TPR filings register — last 30 days of section 28A reports.
• IFTR filings register — last 30 days of section 31 reports.
• FIC s27/s32/s34 register — incoming directives and responses.
• SNTNL alert summary — alerts by risk score (low / medium / high), closure status, average resolution time.
• Customer KYC tier distribution — current population at L1, L2, L3; step-up activity in last 7 days.
• Sumsub onboarding pipeline — applications in flight, EDD pending, declines in last 7 days.
• PEP and adverse media screening — designations identified, decisions taken.
• Cloudlog incident register — open tickets by category, closure SLA.
• Vendor performance — Sumsub and Ravencall uptime, throughput, error rate, last incident.
• Training register — staff training completion, refresher due dates.
• Employee screening register — re-screen due dates by role-risk level.
• Section 43B(4) FIC registration status — current named CO, last update.
• JR partner co-sign register — reports co-signed in last 90 days by partner.
• RMCP version log — version history with approval dates.

Each live evidence page is generated by the underlying system (SNTNL, Sumsub, Cloudlog, goAML) and surfaced here for inspection-readiness. Where the underlying integration is still in build, the page shows a representative dummy with a clear "preview" indicator until live data is wired through.

Travel Rule — daily exchange report

Originator and beneficiary data transmitted on every qualifying crypto-asset transfer, per FIC Directive 9 of 2024 and FATF Recommendation 16.

Summary

Transfers in scope

Each transfer above the FIC Directive 9 threshold below.

Customer references are obfuscated identifiers (KYC-Compliance-only field in Cloudlog); the full customer identity is retrievable from Sumsub by authorised compliance staff.

Originator data fields transmitted

For each transfer, RainFin transmitted the following originator information to the receiving counterparty CASP, per FIC Directive 9 of 2024 and FATF Recommendation 16:

• Full legal name
• Identity / passport number (SA ID for residents; passport number for non-residents)
• Date of birth
• Residential address or country of birth
• Originator's distributed ledger address used for the transfer
• Originator's crypto-asset account number / wallet address
• Transaction details (date, amount, currency)

Counterparty CASP due diligence

All counterparty CASPs in this report passed the SNTNL counterparty-CASP due diligence check at the time of transfer. The check covers: identification of the counterparty (name, registration, regulatory status), assessment of the counterparty's ability to protect confidentiality of transmitted information, and screening against UNSC section 26A(3) lists. CASPs on the approved list are recorded in Counterparty CASP DD.

Pending items

• CUST-C302 / Bybit / 09:01: Bybit acknowledged the originator data submission; reciprocal data on the receiving party expected within 24 hours per Travel Rule SLA. Tracked in Cloudlog ticket CL-TR-20260515-001.
• CUST-NEW-A12 / Coinbase Asia / 09:27: First time RainFin has transacted with Coinbase Asia. SNTNL has flagged for counterparty-CASP due diligence. Cloudlog ticket CL-TR-20260515-002 opened automatically; routed to the Compliance Officer.

Audit trail

Every field transmitted on every transfer is recorded in the SNTNL Travel Rule audit log. The receipt of beneficiary data (where reciprocal) is recorded with the counterparty's signature and timestamp. Records retained for at least 5 years per FIC Act section 23. Searchable by customer reference, counterparty CASP, date range, or asset.

How this connects to the programme

• Transactional Risk — Travel Rule — the control description this report evidences.
• Anonymous crypto transactions — the policy this report demonstrates compliance with.
• Counterparty CASP due diligence — the approved-CASP list that gates this exchange.
• Cloudlog — the case-management system where any Travel Rule exception opens a ticket.

PREVIEW DATA NOTICE. This page currently shows representative data for prototype demonstration. The live integration with SNTNL's Travel Rule API to populate this page from real RainFin transactions is on the Ravencall and RainFin Operations roadmap. Once wired, this page will auto-refresh from SNTNL each time it is loaded, with the underlying SNTNL audit log accessible from any row.

TFS sanctions screening — last run

RainFin's customer base screened against UNSC TFS, OFAC SDN, EU Consolidated, HM Treasury OFSI and POCDATARA designations. Per FIC sections 26A, 26B, 26C.

Summary

Customer-level screening status

The four current Sumsub applicant records and their last screening status. Customer references obfuscated; full identity is in Sumsub.

Screening cadence

• Continuous — Sumsub and SNTNL run ongoing screening on every customer, every transaction.
• On TFS list update — FIC TFS automated email subscription triggers immediate re-screen of full customer base.
• Daily 06:00 SAST — full sweep including OFAC, EU, HM Treasury, UNSC.
• Weekly — adverse media full-base sweep.

Recent TFS list updates consumed

How this connects to the programme

• Customer Due Diligence — Sanctions screening — the control description.
• Sanctions match playbook — what happens on a true positive.
• Outsourcing — Sumsub and Ravencall — the screening function operators.

PREVIEW DATA NOTICE. Once the SNTNL and Sumsub APIs are wired through, this page auto-refreshes from the screening engine on every page load. The underlying screening audit log is searchable from any customer reference.

SNTNL alert summary — last 24 hours

Real-time transaction monitoring alerts from SNTNL by Ravencall. Risk-scored, routed via the four-tier approval workflow.

Summary

Alert distribution by rule fired

High-risk alerts — last 24h

Four-tier workflow status

How this connects to the programme

• Eight platform rules — the rule set generating these alerts.
• Specific monitoring rules R1–R8 — the named rules.
• Cloudlog — where high-risk alerts open tickets.
• Outsourcing — Sumsub and Ravencall — SNTNL is operated by Ravencall under PCC 44A.

PREVIEW DATA NOTICE. Auto-refresh from SNTNL on each load once API integration is live. Drill-down into individual alerts available to authenticated compliance staff.

STR filings register — last 30 days

Section 29 suspicious or unusual transaction reports filed with the FIC via goAML.

Summary

STRs filed in period

No STRs filed in the reporting period.

This reflects that RainFin is in pre-launch / limited-operations for its retail wallet products. SNTNL has raised alerts and Cloudlog tickets in the period (see SNTNL alerts); the Compliance Officer's assessment in each case did not meet the section 29 threshold for filing. The reasons-not-to-file register is maintained in Cloudlog.

Reasons-not-to-file register (last 30 days)

STR monthly review

The Compliance Officer reviews the reasons-not-to-file register monthly to confirm the threshold was correctly applied and to spot patterns suggesting under-reporting. Last review: 1 May 2026. No under-reporting concern raised.

Filing readiness

How this connects to the programme

• Reporting — STR — the procedure this register evidences.
• STR triggered playbook — the operational flow.
• Tipping-off — the discipline applied to every reasons-not-to-file decision.

PREVIEW DATA NOTICE. When integrated, this register auto-updates on every goAML filing and on every Cloudlog reasons-not-to-file decision. Searchable by date, customer, rule, status.

CTR filings register — last 30 days

Section 28 cash threshold reports. RainFin does not currently accept cash transactions; the register is maintained as the control evidence.

Summary

Cash transactions detected in period

No cash transactions detected at any RainFin-controlled account in the reporting period.

Control in place

• SNTNL banking-feed integration with Absa: live. Cash deposits to RainFin's Absa accounts auto-flagged in real time.
• SNTNL banking-feed integration with FNB: in build. Until live, daily manual reconciliation by the Finance Manager in Xero.
• SNTNL R5 (KYC policy violation) — flags any Level 1 customer attempting a transaction above R5,000, which would precede any structuring pattern targeting the R49,999.99 CTR threshold.
• Structuring monitoring (Rule 7) — any sub-threshold pattern targeting CTR evasion auto-routes as STR, not CTR.

If a CTR were triggered

Procedure: see CTR — section 28. End-to-end automated detection through SNTNL, Cloudlog ticket auto-creation, AI Co-Pilot draft of the goAML XML, Compliance Officer one-click approval, automated filing.

How this connects to the programme

• Reporting — CTR — the procedure.
• SNTNL alerts — the monitoring layer that would detect cash.

PREVIEW DATA NOTICE. Once integration is complete, any cash deposit triggers automatic CTR draft in Cloudlog and surfaces here on the next page load.

TPR filings register — last 30 days

Section 28A terrorist property reports. Filed when RainFin is in possession or control of property of a sanctioned, UNSC 1267-designated, or POCDATARA-designated entity.

Summary

TPR filings

No terrorist property reports filed in the reporting period. No true-positive sanctions matches on the RainFin customer base. See the TFS sanctions screening report for the full screening run.

If a TPR were triggered

Detection flows from Sumsub or SNTNL continuous screening. A true positive determination by the Compliance Officer triggers: immediate freezing of assets under FIC Act sections 26A–26C, automatic Cloudlog ticket ("Compliance — sanctions"), AI Co-Pilot draft of the TPR with all required institutional and contact details, Compliance Officer approval, JR co-sign if applicable, filing within 5 days via goAML. See Sanctions match playbook.

Freeze capability

How this connects to the programme

• Reporting — TPR — the procedure.
• Sanctions match playbook — the operational flow.
• TFS screening — the screening evidence.

PREVIEW DATA NOTICE. Auto-updates when integrated. Any new TPR filing surfaces here within seconds of goAML submission.

IFTR filings register — last 30 days

Section 31 international funds transfer reports. Cross-border electronic transfers above R19,999.99 on behalf of, or on instruction of, another person.

Summary

IFTRs filed in period

No qualifying cross-border transfers detected in the reporting period requiring section 31 reporting.

Note: this is consistent with RainFin's current operating model — limited retail launch, AVBOB Wallet customers transact predominantly within South Africa, eZar / XSAV / ESAV Limited Partner transactions are not within the scope of section 31 reporting under their current structure.

What gets reported

• Electronic transfer of funds out of South Africa above R19,999.99.
• Electronic transfer of funds into South Africa above R19,999.99.
• Where RainFin acts on behalf of, or on instruction of, another person (not RainFin's own treasury movements).

SARB exchange control interface

Cross-border crypto flows that touch the exchange control regulations are reported to SARB through the appropriate Authorised Dealer arrangement, in addition to FIC IFTR. The two routes are operated separately.

If an IFTR were triggered

SNTNL detects the qualifying transaction in real time. Cloudlog ticket auto-opens (category "Regulator — IFTR"). AI Co-Pilot drafts the goAML v5.0.2 IFTR XML. Compliance Officer approves; system files within the 3-business-day SLA. See IFTR procedure.

How this connects to the programme

• Reporting — IFTR — the procedure.
• Travel Rule — related but distinct: Travel Rule applies to crypto transfers, IFTR to fiat cross-border.

PREVIEW DATA NOTICE. Auto-updates on goAML filing. Cross-references SARB Authorised Dealer reporting where applicable.

FIC information requests and directives — last 30 days

Incoming section 27 information requests, section 32 additional information requests, section 34 intervention directives — and RainFin's responses.

Summary

FIC requests in period

No section 27, section 32 or section 34 requests or directives received from the FIC in the reporting period.

Inbox monitoring

The goAML inbox is monitored daily by the Compliance Officer and the Head of Operations. Confirmation entries logged each business morning at 09:00 SAST against the daily compliance routine.

Response capability

Historical filings (broader)

The most recent FIC referral RainFin received was the Matthew Hugo Holmes / ANA081 S27 MIREF-260422-0000001 query, responded to on 29 April 2026 by the Head of Operations. Materials retained in the relevant Cloudlog ticket.

How this connects to the programme

• Reporting — FIC requests — the procedures.
• Daily routine — the goAML inbox check that catches s27/32/34 traffic.

PREVIEW DATA NOTICE. Auto-updates from goAML inbox. Each incoming request opens a Cloudlog ticket and the SLA counter starts.

Customer KYC tier distribution — live

Where every RainFin customer sits in the three-tier KYC framework, with step-up activity in the last 7 days.

Summary

Tier breakdown by product

Step-up activity (last 7 days)

No step-up triggers fired in the last 7 days. Consistent with pre-launch operating state.

Cross-wallet linkage status

SNTNL cross-wallet aggregation is live. Across the current 4 records, no multi-wallet linkage detected.

Retrospective step-up programme

Once retail customer launch begins, the retrospective step-up programme (see three-tier KYC) will run to verify existing balances against the new tier thresholds. Programme readiness: 100% (configuration complete, awaiting customer base).

How this connects to the programme

• Three-tier KYC — the framework.
• Cross-wallet aggregation — the always-on linkage rule.
• Sumsub onboarding pipeline — what's in progress.

PREVIEW DATA NOTICE. Live snapshot from Sumsub when integrated. Will refresh on every page load.

Sumsub onboarding pipeline — last 7 days

Applications in flight, EDD pending, declines, and approval throughput from Sumsub.

Summary

Pipeline in period

No new applications received in the reporting period. Consistent with pre-launch operating state for retail wallet products.

Existing pipeline (historical)

Sumsub configuration readiness

How this connects to the programme

• Outsourcing — Sumsub — the PCC 44A disclosure.
• Three-tier KYC — what Sumsub implements.
• Sumsub outage playbook — manual fallback.

PREVIEW DATA NOTICE. Live integration with Sumsub will surface new applicants, EDD progress, decisions in real time on this page.

PEP and adverse media screening — last 30 days

Continuous PEP / FPPO / PIP screening and adverse media monitoring on the customer base and beneficial owners.

Summary

Screening results

No PEP, FPPO or PIP designations identified on the current customer base. No material adverse media events.

Trigger events monitored

• At onboarding — every customer screened by Sumsub on first registration.
• On every transaction — SNTNL continuous screening.
• On TFS list update — re-screen of full customer base.
• Weekly — full-base adverse media sweep.
• On customer profile change — re-screen specific to the customer.

If a PEP designation arises

Cloudlog ticket auto-opens. Foreign PEPs default to high risk per the FIC Act. Domestic PEPs and PIPs assessed on Annexure A indicators. See PEP identified playbook.

How this connects to the programme

• PEP screening control.
• PEP identified playbook.

PREVIEW DATA NOTICE. Auto-refresh from Sumsub and SNTNL once integrated.

Cloudlog incident register — current

Open and recently closed compliance and risk tickets in Cloudlog.

Summary

Open tickets

Closed in last 30 days — by category

AI-drafted findings — review discipline

100% of closed tickets in the last 30 days have a human reviewer-approval of the AI-drafted findings on file. No ticket closed without compliance review.

How this connects to the programme

• Cloudlog control description — the system.
• Outsourcing — Cloudlog is a BMA-arrangement vendor.

PREVIEW DATA NOTICE. Live integration with Cloudlog will surface ticket count, status, SLA in real time.

Vendor performance — Sumsub and Ravencall

PCC 44A vendor performance evidence. Uptime, throughput, error rate, last incident.

Summary

Sumsub Tech Ltd

Ravencall (SNTNL)

Sub-processors

• Sumsub: Chainalysis (on-chain analytics), ComplyAdvantage (adverse media + sanctions).
• Ravencall: Chainalysis, HopTrail (on-chain), Sumsub integration (KYC pass-through for AML screening).

Open vendor items

• Sumsub — overdue invoices (March, April, May 2026 flagged by Xero). Operationally non-blocking; reconciliation in progress with Finance Manager.
• Ravencall — finalising the SNTNL→Cloudlog automated ticketing integration (Key Individual decision 15 May 2026).
• Sumsub tenant naming — bma.network_56176 to be reviewed for RainFin-aligned identifier.

How this connects to the programme

• Outsourcing — Sumsub and Ravencall — the PCC 44A description.
• Annexure G — Vendor register — the formal register.

PREVIEW DATA NOTICE. Quarterly review by the Compliance Officer. Material issues escalated to the Board. Live metrics will pull from vendor status APIs.

Training register — staff completion status

FICA training completion across all staff, refresher due dates, role-specific training records.

Summary

Staff training status

Recent training events

RMCP v2026.1 awareness training

On approval of v2026.1, all staff complete a specific session on the changes (Compliance Officer succession, three-tier KYC, JR co-sign protocol, Cloudlog incident routing, the new automated compliance operating model). Scheduled for the week following Board approval.

How this connects to the programme

• Employees — training and screening — the control description.
• Annual refresher — what the training covers.

PREVIEW DATA NOTICE. Training register auto-updates from Masthead's LMS integration and internal session attendance logs.

Employee screening register — current status

Pre-employment and ongoing screening status by role-risk level. TFS scrutiny tracking.

Summary

Active staff screening status

TFS scrutiny on staff

All active staff screened against the FIC TFS list on every update. Last full sweep: 15/05/2026 06:00 SAST. No matches.

Screening intensity by role

How this connects to the programme

• Employees — training and screening — the control.

PREVIEW DATA NOTICE. HR integration will surface re-screen due dates and TFS scrutiny status in real time.

FIC registration — section 43B(4) status

RainFin's FIC accountable institution registration; current named Compliance Officer; pending notifications.

Summary

Current FIC registration

Notification timeline

• 5 May 2026 — previous Compliance Officer resigned the role with the FIC.
• 7 May 2026 — CAEP Partners proposal signed for KI Application and MLCO Appointments support.
• Currently — CAEP preparing the FIC notification with the new Compliance Officer's details.
• 3 August 2026 — statutory deadline for s43B(4) notification (90 days from resignation).

Other recent FIC interactions

• FIC TFS automated email subscription — active.
• goAML user credentials — Compliance Officer transition in progress.
• FSCA Information Request 2 of 2025 — responded 5 December 2025; no outstanding follow-up.

How this connects to the programme

• Governance — Roles — the current named-holder field.
• About RainFin — registration details.

PREVIEW DATA NOTICE. Auto-populates from CAEP's filing system once the notification is submitted. Will show the date of FIC acknowledgment.

JR partner co-sign register — last 90 days

Regulatory reports co-signed by JR partners. Evidence of the JR co-sign protocol in operation.

Summary

Reports co-signed in period

No regulatory reports filed on JR-onboarded customers in the reporting period. Consistent with pre-launch operating state for AVBOB Wallet retail customers.

JR partners

Co-sign protocol readiness

Forward-looking

AVBOB is transitioning from JR to FAIS licence holder. Once that transition completes, AVBOB takes primary accountable-institution status for AVBOB Wallet customers and the co-sign protocol converts to a handover protocol.

How this connects to the programme

• JR partnerships and co-signing protocol — the control.
• AVBOB Compliance interactions — the partner relationship.

PREVIEW DATA NOTICE. Auto-updates on every co-sign event in Cloudlog once the cross-tenant channel is live.

RMCP version log — programme amendments

Every revision of this programme with date, summary of change, and approving authority.

Summary

Version log

Material amendments since v2025.1

1. CTR threshold correction (R24,999 → R49,999.99) — AVBOB Compliance finding 14 May 2026.
2. PEP / PIP / FPPO terminology aligned to FIC Schedules 3A and 3C — AVBOB Compliance finding.
3. PCC 44A outsourcing disclosures expanded — AVBOB Compliance finding.
4. Product and Service Risk Assessment introduced (Annexure C) — AVBOB Compliance finding.
5. Three-tier KYC framework introduced with R50,000 and R100,000 step-up triggers.
6. Cross-wallet aggregation as mandatory cross-tier control.
7. JR partnerships and co-signing protocol — approved by Key Individual 15 May 2026.
8. Cloudlog as system of record for compliance incidents — approved by Key Individual 15 May 2026.
9. Automated compliance operating model articulated — approved by Key Individual 15 May 2026.
10. Role-based language replacing personal names — discipline applied 15 May 2026.
11. SARS CARF readiness for 1 March 2027.
12. FIC Directive 9 of 2024 Travel Rule procedures (effective 30 April 2025).
13. Compliance Officer succession framework (post Gary Greyvenstein resignation 5 May 2026).
14. Live evidence pattern introduced — inspection-ready click-through from every control description.

Review and amendment

The Compliance Officer reviews this programme at least annually. Minor amendments are approved by the Compliance Officer and noted to the Board; material amendments require Board approval. Each amendment is recorded with date, scope, and approving authority. The PDF snapshot of each Board-approved version is retained as the point-in-time approved record.

How this connects to the programme

• Change log — the static page.
• Programme review — the review process.

PREVIEW DATA NOTICE. Auto-updates on each amendment. Approval timestamps recorded against the Board minute reference.