Unknown block type: SchoolHeader
Unknown block type: SchoolNav

Client Management

One record per client, everything hung off it

What actually goes wrong

Seven reasons nobody can answer the client

Not because the answer is hard. Because it is in four places.

A client calls and asks a simple question: why has my withdrawal not arrived. Answering it means the trading account, the wallet, the last ticket, the KYC file and whatever the sales desk promised in March. In most brokerages those are five systems, and the person on the phone has access to two of them.

So the call ends with somebody promising to find out, and the client learns that the firm does not really know who they are. Everything below is a version of that failure, and the answer to all of it is the same: one record, and everything that ever happened to the client hanging off it.

  1. 01

    The client existed in four systems and agreed with none of them.

    Accounts, documents, deposits, tickets, calls and the introducing partner all hang off a single record. Open a client once and the whole relationship is on the screen — not spread across a trading platform, a payments dashboard, a helpdesk and somebody’s inbox, each holding a different version of the truth.

  2. 02

    The same person was on the books twice.

    Duplicates are caught on email, phone and document number as records are created, and merging keeps the history of both. A client who registered once through an affiliate and again from a search ad is one person with two sources against them, not two relationships that argue with each other at month end.

  3. 03

    A passport expired and nobody noticed until the withdrawal.

    Documents carry their own expiry, and the record starts warning before the date rather than after it. The client is asked for a fresh one while nothing is urgent, instead of at the worst possible moment — when they are trying to take money out and have already lost patience.

  4. 04

    Bank details were changed on the strength of an email.

    Changes to payment details, addresses and contact numbers are requests with an approval behind them, not edits. Who asked, who approved, what it was before and what it is now are all on the record, which is the difference between an inconvenience and a fraud loss nobody can explain to the regulator.

  5. 05

    Nobody could pull a list of the clients who mattered.

    Every field on the record is something you can segment on: country, balance band, platform, account type, last login, deposit history, introducing partner, risk score. Lists built from live data rather than an export from six weeks ago, and reusable rather than rebuilt each time somebody asks.

  6. 06

    The agent who knew the client left in April.

    Notes, calls, mails and promises sit on the record rather than in a person. The next operator to open the client sees what was agreed, when, and by whom — so a handover costs an afternoon of reading rather than a relationship that quietly cools until the client stops funding.

  7. 07

    Everyone could see everything.

    Visibility is set per role and down to the field. A sales desk sees its own book, support sees the client but not the ledger, compliance reads across all of it and changes none of it. Access is the answer to most of what an audit actually asks, and it is easier to set now than to reconstruct later.

What is in it

One record, four things hanging off it

The record is the whole product. Everything below is a way of getting something onto it or out of it.

  1. Part one

    The profile

    Who the client is and how you reach them, plus every custom field your desk needs that we did not think of. Changes to anything sensitive go through approval rather than straight onto the record, and the old value is kept alongside the new one.

    • Personal and contact details
    • Custom fields and tags
    • Duplicate detection on merge
    • Approval on sensitive changes
    • Address and payment detail history
    • Language and communication preferences
    • Consent and marketing opt-outs
  2. Part two

    Everything attached

    Trading accounts across every platform you run, the wallet and its movements, KYC documents and their status, open tickets, the call log and the partner who introduced them. All of it on one screen rather than behind five logins, and all of it live rather than synced overnight.

    • Trading accounts on MT5, cTrader and the rest
    • Wallet balance and movements
    • Deposits, withdrawals and transfers
    • KYC documents with expiry dates
    • Support tickets and their history
    • Calls, mail and notes
    • Introducing partner and rebate tag
  3. Part three

    Segments and lists

    Any field, any combination, saved and reused. A segment is a live query rather than a snapshot, so the list of clients who have not funded in ninety days is right on the morning somebody opens it rather than right on the morning it was built.

    • Saved segments on any field
    • Balance, volume and activity bands
    • Last login and last deposit
    • Country, platform and account type
    • Risk score and KYC status
    • Bulk actions on a segment
    • Export where the role allows it
  4. Part four

    Access and the trail

    Who may open a record, which fields they may read, which they may change and what they may approve. Every action against a client is written down with the operator and the time, and the trail cannot be edited from inside the console by anyone at all.

    • Role permissions to field level
    • Book visibility per desk
    • Approval limits on the operator
    • Read-only compliance access
    • Full action trail per client
    • Login and export logging
    • Data retention rules

Who signs in

One record, six ways of reading it

The same client opens differently depending on whose login it was opened with.

  • Support. The client, the last deposit, the open ticket and the account balance already on screen when the call is answered — so the first thirty seconds are not spent asking the client to identify themselves twice.
  • Sales. Their own book and its history: what was promised, what was funded, what lapsed. Nothing from another desk’s clients, which settles the ownership argument before it is had.
  • Onboarding. The document queue and the expiry warnings, with the client record beside each one rather than a filename and a hope that it belongs to the right person.
  • Finance. The wallet, the movements and the payment details, with the approval trail behind any change to them. Limits sit on the operator, so a stand-in never inherits a larger one.
  • Compliance. Read across every client and change none of them, and pull the trail without asking another team to run an export first. The answer is ready before the question is asked.
  • Management. Segments rather than individuals: who is funding, who has gone quiet, which country is growing and which partner’s clients actually stay.

A client does not care how many systems you run. They notice the moment you cannot answer them.

Questions about the module

Before you move your book across

The things worth settling before a live client base changes systems.

  • Yes, and they behave like the fields that ship with it. Custom fields can be text, numbers, dates, currencies or lists, they can be required at a particular stage, they can be restricted to certain roles, and they can be segmented on and reported from like anything else. Most desks add a handful in the first month — a regulatory category, an internal risk grade, a referral note — and the point is that those become part of the record rather than a comment field somebody agreed to keep updated.

  • To the field. A role decides which clients open at all, which sections of the record are visible, which fields can be read, which can be changed and what the operator is allowed to approve. A sales desk sees its own book and nothing from another; support can open any client but not the ledger; compliance reads everything and writes nothing. Approval limits sit on the operator rather than the department, so covering for someone on leave never quietly hands over a larger limit than it should.

  • They merge, and nothing is thrown away. Duplicate detection runs on email, phone and document number as records are created, so most never get that far; when one does, merging keeps both histories, both sources and both sets of documents against the surviving record, and notes which record it came from. Trading accounts and wallet movements follow the merge, and the introducing partner tag on each is preserved — which matters, because a merge that quietly reassigned a rebate would be a worse problem than the duplicate was.

  • It holds them. Identity documents, proof of address, bank statements and anything else a client uploads sit on the record with their type, their status, who approved them and when they expire. Expiry is the part most systems miss: the record warns before the date rather than after it, so the request for a fresh document goes out while nothing is urgent instead of on the morning the client is trying to withdraw and is already annoyed.

  • That is what segments are for. Any field on the record can be a condition, conditions combine, and the result is saved and reused rather than rebuilt. Clients in Malaysia on MT5 who funded once and have not logged in for ninety days is a segment, not a ticket to the data team. Because a segment is a live query rather than a snapshot, the list is right on the morning it is opened, and bulk actions run against it where the role permits.

  • Client records, trading accounts, documents that were already verified, wallet balances, the partner tree and the history attached to all of it. A client who logs in after the move finds the account they had rather than a blank one, and an operator opening a record finds the notes their predecessor left. Platform connections are set up alongside the migration, so a desk switching systems is not also switching how it trades while it learns a new console.