Purpose & value
This platform is the technology backbone for a cross-border chrome trade. It secures the whole flow: order creation, counterparty verification, assignment, cross-border movement, last-mile delivery, and milestone-based settlement.
Why it exists
Zimbabwe prohibits the export of raw chrome ore — the ban was reinstated in 2022 and extended to all raw minerals in February 2026 after ore was found stockpiled at border points. Only beneficiated product — chrome concentrate and ferrochrome — may be exported, and only through the Minerals Marketing Corporation of Zimbabwe (MMCZ), against an export permit and assay certification, with ZIMRA customs clearance. South Africa has tightened its own chrome regime and remains on the FATF grey list, raising due-diligence expectations on counterparties.
In a trade where smuggled and informal flows are the known failure mode, the platform is a provenance-and-trust rail: it produces the auditable chain of custody, the verified counterparties, and the secure settlement that let compliant operators transact with confidence and prove legitimacy to regulators, banks and buyers. The washing step is the legal gate that makes product exportable; the documentation, tracking and escrow are the proof of legitimacy that wins against the informal market.
The rules above informed the design and are working assumptions. Export controls, MMCZ / ZIMRA / SARS procedures, FICA / POPIA obligations, and the escrow provider's licensing all move quickly and must be confirmed with local counsel before build.
Operating model & phasing
CCSA Chrome — the operator and engaging client — is a principal party to each trade, not a neutral marketplace. The build ships as an agent and grows into a washhouse.
Agent
CCSA Chrome brokers a deal between a third-party supplier (a Zimbabwean producer or washing plant) and a buyer, earning a commission or spread. No title to the chrome. Value = trust, compliance, logistics and secure settlement.
Washhouse / Principal
CCSA Chrome takes title: buys ore, washes and beneficiates it, and sells concentrate on a margin. Adds an inventory-and-processing layer — stockpiles, wash batches, yield, grade upgrade (Cr₂O₃ in vs. out), tailings, QA / assay.
Design for the washhouse, ship the agent. Both models share nearly all the machinery — KYB, documentation, tracking, escrow and cross-border compliance are identical. Phase 1 ships the agent, but the data model reserves the washhouse entities from day one, so Phase 2 is a feature expansion, not a rebuild. CCSA Chrome is modelled as a party whose role can flip from agent to principal.
Money-flow implication. As agent there is one escrow leg (buyer → escrow → supplier, less fee). As principal there are two linked legs (CCSA Chrome pays the supplier for ore; buyer pays CCSA Chrome for concentrate). Both are legs that reuse a single order / escrow / tracking pipeline — so the pipeline is built once.
Who uses it
Everyone works through one role-based app — from CCSA Chrome's ops desk to a driver at the weighbridge. In Phase 1 the buyer and supplier are always third parties; CCSA Chrome's roles sit above the deal.
Buyer
Smelter, trader or exporter — domestic (SA) or offshore.
Supplier
Zimbabwean producer or washing-plant operator.
Transporter & drivers
Fleet operator plus individual drivers running the load.
Ops & logistics
Order and assignment management, dispatch, tracking.
Compliance officer
KYB, document verification, escrow oversight.
Finance / escrow admin
Funding, releases, reconciliation.
Platform admin
Configuration, roles, audit.
Broker / agent
External intermediary on a specific deal.
Weighbridge / assay lab
Evidence capture only — weights and grade.
Order to delivery
The deal moves along one pipeline. Milestones marked ◆ trigger an escrow release. Every transition records who, what, when and on what evidence — an immutable audit trail.
- SetupOrder createdDeal opened with quantities, grade spec and terms.
- ComplianceCounterparties KYB-verifiedBoth sides checked before the deal can proceed.
- ContractContract / PO signedPayment terms, release schedule, provisional & final-price formula.
- EscrowBuyer funds escrowFunds held at LUXEPAY; seller notified and confirms.
- AssignmentTransporter assignedLoad dispatched to the collection point.
- CollectionLoaded at plant / mineWeighbridge-out, assay sample, loading docs.Shipping weight → proportional release
- Cross-borderExport & customsMMCZ export permit, ZIMRA and SARS clearance.
- TransitIn-transit trackingGPS telematics from border to destination.
- DeliveryArrival & acceptanceWeighbridge-in at destination.Arrival weight → proportional release
- QualityAssay resultConfirmed Cr₂O₃ grade sets final price.Purity / grade → final settlement
- CloseTrue-up & archiveFinal settlement reconciled; documents archived.
The escrow engine
LUXEPAY is the licensed financial rail — every party (buyer, supplier, CCSA Chrome) holds an account, a pattern already proven in the LUXE24 setup. LUXEPAY holds a wallet per user; the platform tracks deal-level allocations against those balances, so a wallet can never be oversubscribed across concurrent deals.
Funded pot
The buyer's money held at LUXEPAY against this deal.
Release schedule
Ordered tranches — amount / %, unlocking milestone, payee(s).
Milestone gates
Type, evidence, approver, tolerance, status. "Met" fires a release.
Ledger
Double-entry mirror of LUXEPAY, reconciled by webhook.
Provisional draws, then a true-up
A provisional price is set at contract. The final price recalculates against actual arrival weight × price-as-a-function-of-actual Cr₂O₃ grade. Every interim release is therefore a provisional draw; the final tranche settles the gap.
- Releases are one-way. Funds are hard to recover once disbursed, so the provisional price and early tranches are set conservatively — discounted to expected value — so the true-up is virtually always a top-up, never a clawback. This mirrors standard concentrate practice: provisional invoice at a discount, final invoice on assay.
- Proportional release. Each interim tranche scales to its own measurement. Tolerance bands govern out-of-spec actuals: release proportionally, hold, or raise a dispute.
- Front-loading is flagged. The platform warns on any schedule that releases a large share before the quality and weight milestones that determine final value.
Authorisation is role-aware
A milestone being approved (evidence) is separate from a release being authorised (the instruction to LUXEPAY). As agent, CCSA Chrome is neutral, so it authorises releases on an approved milestone, with the buyer notified and given a short objection window on the highest-risk tranches. As principal, CCSA Chrome is a counterparty — self-authorising would be a conflict — so authorisation shifts to automated, data-triggered releases and/or buyer co-sign. It is built as a rule, not hardcoded.
On the highest-risk tranches (the large early release and the final top-up): buyer co-sign, or CCSA Chrome authorises with an objection window? See section 09.
Documents & compliance
Generates Formal documents
- Sales contract / PO
- Certificate of origin
- MMCZ export permit reference
- Weighbridge tickets — out & in
- Assay / QA certificates
- Loading & delivery notes
- ZIMRA / SARS customs documents
- Commercial invoice — provisional & final
- Settlement statement
Supports Compliance
- KYB — CIPC company & director checks
- SA ID (Home Affairs) & bank-account verification
- AML / PEP / sanctions screening
- UBO capture — now mandatory under FICA
- FICA obligations & POPIA data protection
- Enhanced due diligence (FATF grey-list)
- MMCZ permitting & assay certification
- ZIMRA customs clearance
- Immutable audit trail across the deal
Whether MMCZ / ZIMRA expose any API — assume a manual document workflow until confirmed — and LUXEPAY's FSP / licensing posture for holding third-party funds.
Integrations
LUXEPAY
Escrow rail. Webhooks for fund, allocate, release, refund; multi-payee split disbursement. Proven in LUXE24.
KYB aggregator
CIPC, ID, bank AVS, AML / PEP, UBO. Candidates: VerifyNow, ThisIsMe, Datanamix, Didit — to select.
Fleet GPS telematics
Cartrack / Netstar-class provider. Subject to existing hardware.
Generation & e-signature
Contracts, permits, tickets, certificates, invoices.
Notifications
WhatsApp Business API (regional default) plus SMS & email.
Weighbridge & assay feeds · FX
Direct data feeds; FX / SARB exchange-control handling.
The application
Every participant works through one application — mobile-first and role-based — so a driver at a weighbridge, a supplier in Zimbabwe, a buyer's trader and CCSA Chrome's own teams all act on the same live deal, from wherever they are.
What each person sees is scoped to their role: counterparties work only their own deals; drivers get a stripped-back capture view — scan, weigh, photograph, confirm — that holds up on the patchy connectivity around the border; and CCSA Chrome's team gets the full operational picture, escrow status and exceptions, plus the management dashboards and reporting the business runs on.
Buyer & supplier
Agree the deal, sign documents, fund and confirm, and follow the load in real time.
Transporter & driver
Accept assignments and capture evidence on the move — weights, photos, delivery.
CCSA Chrome team
Run ops, compliance and finance — pipeline, releases, audit trail, dashboards.
Under the app sits a Django + DRF API — one source of truth for deals, documents, tracking, escrow state and the audit trail, serving every role's view and the reporting layer.
Open for sign-off
- Escrow authorisation on high-risk tranches — buyer co-sign, or CCSA Chrome authorises with an objection window?
- Phase-2 washhouse location — almost certainly in Zimbabwe (near the Great Dyke), since raw ore can't be exported, so washing happens ZW-side and concentrate is exported. Confirm — it shapes Phase-2 sourcing.
- KYB aggregator selection — confirm coverage, especially UBO and cross-border.
- Fleet — own vs. contracted trucks; existing GPS hardware / provider.
- LUXEPAY — confirm licensing / FSP posture and the exact API surface (fund / allocate / release / refund / webhooks; authorisation model — currently TBC).
- Regulatory specifics — confirm MMCZ / ZIMRA / SARS / FICA / POPIA details with local counsel.
After sign-off
Planning document
Scope, milestones, phasing, resourcing.
Database schema
Agent model live, washhouse entities reserved.
Wireframes
App-based flows for each user type.
Coming into this document next
This brief is built to grow. Wireframes, the schema diagram and process visuals drop straight into the frames below as we flesh them out — all viewable here, on any device.