# Financial services > One governed view of customers, accounts, agents and transactions across core banking, mobile money and branch networks, so risk, fraud, credit and compliance teams work from the same facts. Vertical ontology, workflows and compliance notes for financial services in Africa. Canonical URL: https://www.boltcliq.com/industries/financial-services Part of: https://www.boltcliq.com/llms.txt One governed view of customers, accounts, agents and transactions across core banking, mobile money and branch networks, so risk, fraud, credit and compliance teams work from the same facts. - Sector pack: Starting ontology for banks, lenders and payment firms - Core + wallets: Typical sources: core banking, mobile money, card and agent systems - Central bank + DPA: Regulators in scope, named per country - USSD to API: Channels: branch, agent, USSD, WhatsApp, web and mobile ### The challenge - A typical African bank or lender runs several systems that were never designed to talk to each other. A core banking platform holds accounts and ledgers. A separate mobile money platform holds wallets. Agent networks report on spreadsheets or a standalone app. Card, switch and payment gateway data sit with processors. KYC records live in a case tool, in scanned PDFs, and sometimes in a branch filing cabinet. Each system has its own idea of who the customer is, often keyed by a different phone number, national ID or account number. - The gaps show up when someone needs one answer across systems. A fraud analyst cannot see that a wallet, a loan and a card belong to the same person without a manual lookup. A credit officer decides on a thin file because the mobile money history is not joined to the branch record. Compliance teams rebuild the same regulatory report each month from extracts. AI pilots stall because the data is not labeled, not permissioned and not traceable. Without a shared model and an audit trail, nobody can say which data a decision used. ### The ontology **Objects** - 12 core things - The nouns of the sector. Each object has an identity, properties and a history, and maps to records in the source systems. - Customer - Account - Wallet - Transaction - Loan - Agent - Branch - KYC record - Alert - Case - Product - Regulatory report **Links** - 8 core relationships - How the objects connect. Links turn separate tables into a graph that people and agents can walk. - Customer holds Account and Wallet - Account posts Transaction - Loan is secured by Account or collateral - Agent serves Customer and originates Transaction - Alert is raised on Transaction - Case groups Alerts and evidence - KYC record verifies Customer - Report is built from Transactions and Accounts **Actions** - 6 governed actions - What people and approved agents may do. Each action has rules, an approver where needed and a log entry. - Approve or decline a loan - Freeze or release an account - Escalate a fraud alert to a case - Refresh KYC for a customer - Restructure a loan - File a suspicious activity report ### Use cases - Credit - A microfinance lender receives hundreds of loan applications a week through agents. Each file has a scanned form, a phone number and whatever bank or wallet history the applicant can show. Officers spend most of their time chasing missing documents instead of judging risk. - The ontology joins the applicant across core banking, wallet and repayment history, and flags gaps in the file. A governed agent assembles a credit summary with the sources behind every figure. It proposes a limit and a term and lists the signals that moved the recommendation. - The credit officer approves, adjusts or declines. Policy limits are enforced by the system, and the officer can override with a recorded reason. The customer can be told which factors mattered. - Fraud - SIM swap and account takeover fraud spike around salary days. Alerts arrive from the core system, the wallet platform and the card switch, each with different identifiers. Analysts open three tools to decide whether one alert is part of a pattern. - Alerts attach to a single customer object, with linked devices, agents and recent transactions. An agent drafts a case summary and suggests related alerts. It can place a temporary hold only if policy allows and the action is logged. - The fraud analyst confirms the pattern, releases or extends the hold, and decides whether to escalate. High value actions need a second approver. - KYC and onboarding - A bank onboards customers through branches, agents and a mobile app. Identity checks use national ID lookups and document scans, and review queues grow when a provider is slow or a scan is unreadable. - OCR and ID lookups feed a KYC record linked to the customer. Missing or mismatched fields are flagged before review. Low risk files move through a defined path, and unusual ones are routed to a reviewer with the evidence attached. - A compliance officer approves higher risk customers and signs off on exceptions. Rules for what counts as low risk are set by the bank, not by the model. - Agent network - A bank or wallet provider relies on thousands of agents for cash in and cash out. Float runs short in some locations and sits idle in others. Field staff learn about shortages after customers are turned away. - The ontology models agents, locations, float balances and transaction patterns. It predicts likely shortages, proposes rebalancing and notifies field teams by SMS or WhatsApp. Suspicious agent behavior is surfaced for review. - The agent network manager approves rebalancing plans and decides on sanctions or training for flagged agents. ### Data you already have - We read from your existing systems first and write back only through approved actions. Every source has a named owner. Where connectivity is weak or records are on paper, we plan for queued sync and OCR with human review. - Core banking and general ledger systems, often on premises - Mobile money platforms and wallet ledgers - Agent network apps, float reports and spreadsheets - Card switch, payment gateway and processor files - KYC case tools, national ID lookups and scanned documents - Loan origination and collections systems - Call center and WhatsApp conversation logs - Regulatory return templates and prior submissions ### Compliance and residency - Nigeria - NDPA 2023 and central bank rules - Customer data, consent and cross-border transfer may need documented controls. Banks may face in-country hosting expectations. - Kenya - Data Protection Act 2019 - Registration, consent and purpose limits shape how customer data is joined across systems. Central bank guidance on outsourcing may also apply. - South Africa - POPIA - Lawful processing, security safeguards and breach notification apply to customer records, with sector regulator expectations on top. - Ghana - Data Protection Act 2012 - Data controllers register and follow principles on purpose, retention and security. - Rwanda - Law on Personal Data Protection 2021 - Rules on storage and transfer outside the country may affect where analytics can run. - Anti money laundering, consumer protection and outsourcing rules differ by country and by license type. This list is illustrative only. Confirm with counsel which laws and regulator guidance apply to your institution. Examples only, not legal advice. Confirm with counsel. ### Boltcliq products **Zeus** - Model plane - Models customers, accounts, wallets, agents and alerts as linked objects, and defines the actions banks take on them. Zeus also drives the dashboards credit, fraud and finance teams use. **Odin** - Trust plane - Controls which staff, agents and AI systems can see customer records or trigger actions such as a hold. Access follows role, branch and purpose, and every grant is recorded. **Monolith** - Control plane - Gives credit and fraud agents the context they need, filtered by policy, and blocks actions outside their remit. It keeps memory of past cases from leaking across customers. **Argus** - Runtime plane - Runs agents and stores the data privately, in your cloud account or a jurisdiction you choose, so customer data stays where the regulator expects it. **Cyclopes** - Observation plane - Records which data and rules produced each credit, fraud or reporting decision. Examiners and internal audit can replay a decision with its inputs. ### Frequently asked questions - Does Boltcliq replace our core banking system? - No. The ontology sits on top of core banking, wallets and other systems. It reads from them and writes back only through actions you approve. - Can customer data stay in our country? - That is a design requirement. Confirm the exact option for your market during scoping. - How do you handle mobile money and agent data? - Through connectors and file feeds from the wallet platform and agent apps. These sources join the customer object, so one person is one record across rails. - Will AI make credit or fraud decisions on its own? - Not by default. Agents prepare summaries and propose actions. Approval thresholds are set by your policy, and humans approve anything above them. - What about paper and scanned documents? - OCR and review queues bring documents into the KYC and loan objects. Poor scans are flagged to a person rather than guessed.