Every Customer in One Place: Profiles, Documents, Risk and History for Support and Compliance

A customer calls to ask why their transfer has not gone. The support agent opens one system for the profile, another for the identity documents, a spreadsheet for the limits, and asks compliance by chat whether there is a risk flag. Twenty minutes later the customer gets an answer that may not match what they were told last week. The fix is not a faster agent. It is one record per customer that support and compliance both read, with each person seeing only what their role allows.

This guide is for operations, support and compliance leads at established money transfer operators who already have thousands of customers on the books and want every question about one of them answered from the same place.

RemitSo is one way to run this. Its Customers module brings each customer's profile, documents, risk page, payment accounts, devices and login sessions, notes, sanction lookups, account updates and limit card into one record, with access controlled by permission. It does not make the decisions: your team still reviews documents, rules on screening matches and decides what to tell the customer. This guide sets out how to organise that work on any platform.

Start from the questions people actually ask, not from the database tables. Almost every question about a customer falls into one of six groups.

• Who they are: the profile, with the details collected at sign-up and during identity checks.
• What they have proved: identity and supporting documents, with each one's review status, and any that were rejected or removed.
• How risky they look: the risk indicators that fired, why, and what was decided.
• How they pay and sign in: payment accounts, devices and login sessions.
• What they can do now: the limits that actually apply, and what they would need to provide to send more.
• What has happened before: notes, screening results, account updates and requests the customer has made.

If any of these lives outside the customer record, someone will eventually answer from memory, and that is where inconsistent answers and gaps in the evidence come from.

A short map turns a new agent into a useful one within a shift, and it keeps answers consistent across the team. Build yours from the questions in your own ticket history; the table below is a starting point based on the parts of a RemitSo customer record.

Two habits make the map work: agents quote what the record says, not what they remember, and a question the record cannot answer is logged as a gap to fix, not worked around with a private spreadsheet.

A risk score on its own tells an analyst that something is wrong, not what. The useful version reads like a case file: each check that fired explains itself, links to the records that tripped it, and keeps the evidence.

In RemitSo, a customer's risk page works this way. Each trigger is written in plain language and links to the records behind it, drawn from 46 ready-made risk indicators, such as a possible duplicate customer, a mismatch between profile and document data, frequent transfers to the same recipient, payment details reused across customers, or a sign-in IP from a high-risk country. The analyst starts from the reason, not from a number.

How to work a risk page

1. Read every trigger, not only the first. Two weak signals together often matter more than one strong one.
2. Follow each link to the record. A "payment details reuse" trigger means nothing until you have seen which other customer used the same account.
3. Check the rest of the record for context. Devices, sessions and payment accounts often explain a trigger innocently, or confirm it.
4. Write the decision and the reason. The next analyst should not have to repeat your work.

Account takeover and first-party fraud both leave traces in the same three places: where the customer signs in from, on what device, and with which payment account.

• Login sessions: in RemitSo every sign-in by a customer is logged with time, IP address, city, country, client app, operating system and whether two-step sign-in was completed. A first sign-in from a new country, a new device and a new payment account on the same evening is worth a call.
• Devices: customers can see every signed-in device in the app and remove a lost phone in one tap, after which its sessions, PIN and Face ID sign-in stop working. Your team sees the same devices on the customer record, so support and the customer are looking at the same list.
• Payment accounts: the accounts a customer has paid from. Several new ones in a short window, or one shared with another customer, deserves a look before the next transfer clears.

A customer who reports a lost phone gets a quick, specific answer, and your team has the evidence if the account was misused.

Notes

Write notes for the next person, not for yourself: what the customer asked, what was decided, what was promised and by when. "Customer called re held transfer; explained additional ID needed; sent document request" is useful. "Called, sorted" is not.

Account updates and requests

Account updates sit on the same record, as do account requests. A request to close an account, for example, is made simply in the app and waits for a decision by your team rather than taking effect on its own. The customer gets a clear route; your team gets the chance to check for transfers under way and record-keeping obligations before acting. Our guide to closures, data changes and access requests covers how to verify and decide each one.

Sanction lookups

Every screening of the customer, what it matched and what an officer decided, sits on the record. A ruling that a match is "not this person" stays unless revoked, so a cleared customer is not flagged again every time the lists reload. That spares the customer repeated holds and spares your officers repeated reviews. For the wider programme, see sanctions screening for remittance companies.

One record per customer does not mean everyone sees all of it. Support needs to answer the question in front of them; compliance needs the full case; finance needs payments. The risk is in the export and the screen nobody thought about.

• Grant transaction details field by field. In RemitSo, transaction details can be granted field by field, so a support role can see status and delivery method without seeing everything else.
• Treat bulk export as its own decision. Download Customers is a separate permission in RemitSo. Viewing one customer to help them is routine; downloading the whole customer base is not, and most roles should never have it.
• Keep the risk page with the people who act on it. Decide deliberately whether front-line support can open it.

For a fuller approach to roles, see role-based access control for remittance operations.

The details below are illustrative, chosen to show the reasoning rather than to describe any real operator or customer.

A long-standing customer, who has sent regularly for two years, calls at 14:00. Their latest transfer is waiting and they want to know why.

Step 1: support opens the record

The agent opens the customer and checks the limit card. The customer's total over the past 90 days has crossed a threshold set in the operator's AML rules, and the next tier asks for proof of source of funds. The documents show nothing submitted yet. The agent explains that, at this level of sending, the operator needs one additional document, says which, and confirms the customer will be told what to upload. The call takes four minutes. The agent writes a note.

Step 2: compliance looks at the same customer

At 15:30 the same customer appears on the compliance queue. The risk page shows two triggers in plain language: a sign-in from a new country, and a new payment account. Each links to its record. The login sessions show the new country, a new device and two-step sign-in completed. The notes show the support call from 14:00, so the analyst knows the customer is engaged and has been asked for a document.

Step 3: decide and record

The profile shows the customer's address is now in that country, which explains the sign-in. The new payment account is in the customer's own name. The analyst records that the triggers are explained and leaves the transfer waiting only on the source-of-funds document. When the document arrives the next morning, it is reviewed and approved, and the transfer moves on.

What changed

The customer had one consistent answer from the first call, and neither team repeated the other's work. If an examiner later asks why the transfer was held and released, the triggers, evidence, document and both teams' notes are on one record.

RemitSo's Customers module puts each customer's record in one place in the admin panel, with access set by permission. See the admin features and the customer app features.

• One customer record (both): profile, documents, risk page, payment accounts, devices and login sessions, notes, sanction lookups and account updates together, so your team answers from one place and your customers get the same answer whoever they speak to.
• Risk page as a case file (your team): each trigger explained in plain language, linked to the records that tripped it, with the evidence kept, so analysts start from the reason and can show an examiner why a decision was made.
• Limit card (both): shows the limits that actually apply to the customer, so support can explain a held or refused transfer precisely and customers know what to do to send more.
• Documents with review status (both): approved, rejected with a rejection label, or removed with a reason and kept under a Deleted tab, so customers are told clearly what is missing and your team has the history.
• Devices and login sessions (both): every sign-in logged with location, app, operating system and two-step status; customers can remove a lost phone in one tap, and your team sees the same list.
• Sanction lookups on the record (both): every screening, its matches and the officer's decision; a cleared customer is not flagged again, which spares them repeated holds.
• Field-by-field access and a separate Download Customers permission (your team): each role sees what its job needs, and bulk export is a deliberate grant, which protects your customers' data.
• Wallet card (both): where you offer wallets, an optional add-on where your licence allows, the customer's wallet is visible on their record.

What your team still does: review documents, rule on risk triggers and screening matches, decide account requests and write the notes that make the record useful. To see it in practice, book a demo.