ForexFox stores a complete KYC record for every client. Identity documents, tax residency, source of funds, profession, PEP status, and an AI risk score field are all captured in a structured model. The same record powers compliance rule evaluation, transaction history retrieval, and client-level blocking — from one unified data source.
ForexFox captures every field that AML/CFT compliance requires for exchange office operations: full identity data, two forms of document with expiration date, physical address, tax residence country with TIN/NIF, source of funds, and profession category. These are not optional fields added as an afterthought — they are structured columns in the client model, indexed where relevant, and directly consumed by the compliance engine when evaluating required_fields rules. A client record in ForexFox is designed to pass supervisory inspection, not just complete a form.
Each client carries an is_pep boolean and a free-text pep_details field for documenting the nature of political exposure. A numeric risk_score_ai field (DECIMAL 5,2) is available for output from a risk classification model or for manual assignment by a compliance officer. Both fields feed directly into compliance rule logic — a high risk score or a PEP flag can trigger enhanced due diligence paths, additional required fields, or approval routing, without any custom development. The infrastructure for risk-based client management is already in place.
ForexFox maintains a client_lifetime_totals table that accumulates the total EUR volume transacted by each client across their entire relationship. This feeds directly into compliance rules scoped to lifetime_client, enabling thresholds that are impossible to enforce without a persistent cumulative record. Daily totals are maintained separately in tx_daily_totals for rolling-period rules. Both tables are updated atomically with each transaction, so threshold evaluations always reflect current exposure — not yesterday's batch.
Any client can be blocked by an admin or root user, with a mandatory reason recorded in the block_reason field. Blocked clients cannot be used in new transactions — the status is checked at the counter before any operation is initiated. The block reason is visible to compliance officers and managers for review decisions, and the full audit trail shows when the block was applied and by whom. This gives operations teams a controlled, traceable mechanism for handling high-risk clients without deleting records or losing transaction history.
Identify and retrieve client records quickly during high-volume counter interactions.
Maintain KYC data quality and apply risk classification across the client base.
Use client-level data to drive compliance rules and monitor exposure per client.
See how this solution maps to your operational constraints and compliance requirements.
See the CRM in a demo