A practical guide to building a compliance dashboard that brings KYC, transaction reviews, sanctions screening, customer risk, document expiry, and compliance worklists into one operational view.
Compliance teams at money transfer businesses often work across multiple screens to understand which customers are waiting for identity verification, which transactions are held for review, whether sanctions screening has produced potential matches, and where customer risk is concentrated. A well-designed compliance dashboard brings these signals together so teams can identify, prioritize, investigate, and act on compliance issues without manually connecting information across the platform.
In This Article
A compliance dashboard is a centralized view of compliance-related activity across a money transfer platform. Instead of requiring a compliance officer to visit several pages, the dashboard summarizes the most important information in one place.
A practical dashboard may bring together:
The objective is not to replace detailed compliance workflows. It is to help the team identify what needs attention first.
One of the biggest mistakes when designing a compliance dashboard is starting with the visual design. Instead, begin by asking what questions the compliance team needs the dashboard to answer.
| Compliance Question | Dashboard Signal |
|---|---|
| Who is waiting for KYC? | Pending identity checks |
| Which transactions need attention? | Transactions on hold |
| Are customers producing screening hits? | Screening results |
| Where is customer risk concentrated? | Risk distribution |
| Which documents need renewal? | Expiring documents |
| Which customers need investigation? | Compliance worklist |
Every widget should exist because it answers a meaningful operational question. If a chart looks impressive but does not help the compliance team make a decision, it probably does not belong on the dashboard.
Identity verification is one of the most important compliance workflows in a remittance business. A dashboard should help teams quickly identify customers whose verification process requires attention.
Useful indicators can include:
The dashboard should ideally allow the compliance officer to move from the metric to the underlying customer records. A number without a workflow is less useful than a number that leads directly to action.
Not every transaction can be processed automatically. Depending on the platform's AML rules, transactions may be placed on hold for manual review.
A compliance dashboard should therefore provide visibility into:
24 transactions require compliance review
→ View the underlying transactions → Open the authorised review workflow
This turns the dashboard from a reporting page into an operational worklist.
A compliance dashboard is most useful when important indicators lead directly to the customers, transactions, and cases that require action.
Sanctions screening should have a prominent place on a money transfer compliance dashboard. Depending on the screening system and available data, useful indicators can include:
The important point is to clearly distinguish between potential match and confirmed match. These are not the same thing.
A screening hit may ultimately be determined to be a false positive. The dashboard should therefore reflect the actual states supported by the underlying workflow rather than assuming that every hit represents a confirmed sanctions match.
Money transfer businesses may screen customers against multiple sanctions and watchlists. It can be tempting to create a separate dashboard section for every watchlist, but this can quickly make the dashboard difficult to use.
A better approach is to consolidate related screening information where the underlying data overlaps. For example, sanctions screening can include per-list counts rather than creating separate sections that repeat the same screening information.
A compliance team needs to understand not only individual high-risk customers but also the overall distribution of customer risk.
A risk distribution widget might show:
A sudden increase in high- or critical-risk customers may warrant further investigation. However, risk categories must have consistent definitions across the platform.
If one page calls a customer Very High Risk while another calls the same band Critical, reporting and filtering become confusing. A single risk-band definition should be used throughout the system.
Charts tell compliance teams what is happening. A worklist tells them who needs attention.
This is one of the most valuable parts of a compliance dashboard. A worklist could identify customers carrying the most uncleared compliance risk and provide direct links to their profile, transactions, screening history, and compliance information.
| Customer | Risk | Open Issues | Action |
|---|---|---|---|
| Customer A | Critical | 4 | Review |
| Customer B | High | 3 | Review |
| Customer C | High | 2 | Review |
This eliminates the need for compliance officers to manually search for the customer after identifying a risk indicator.
Customer verification does not necessarily end when an identity document is accepted. Documents can expire, and a compliance dashboard should help teams identify documents that are approaching their expiration date.
Useful categories could include:
This gives the compliance team an opportunity to take action before an identity document becomes a larger operational issue.
This is one of the most important principles when building a compliance dashboard.
It is tempting to include every AML metric that appears in a requirements document. But if the platform does not collect the underlying data, the metric cannot be reliably calculated.
For example, a dashboard may propose metrics for:
Compliance dashboards deal with sensitive operational information. A number that looks precise can be misleading if the underlying data is incomplete.
For example, if the system records potential sanctions hits but does not record whether a hit was ultimately confirmed, the dashboard should not present a confirmed match count.
Instead, it should show the states the system actually knows.
A dashboard should represent what the platform knows, not what stakeholders wish it knew.
A compliance officer should be able to understand where a dashboard number comes from.
Suppose the dashboard shows:
This creates a relationship between:
Without this connection, dashboards become reporting screens rather than compliance tools. Where possible, make important metrics clickable.
Compliance information is sensitive. Not every administrator should necessarily see every dashboard section.
A better architecture is to control dashboard sections through permissions.
This provides more granular control than giving every role access to the entire dashboard. Permission design should therefore be considered part of the dashboard architecture, not an afterthought.
Bring customer, KYC, AML, screening, risk, and transaction information together while keeping detailed actions inside authorised workflows.
Compliance dashboards can involve substantial database queries. If every widget loads simultaneously, the user may have to wait for multiple queries before seeing anything.
A better approach is to load dashboard sections independently:
This creates a faster perceived experience. It also means one slow query does not necessarily prevent the rest of the dashboard from becoming usable.
A compliance dashboard should generally be a visibility and decision-support layer rather than a place where data is silently modified.
This separation reduces the risk of accidental changes from a reporting interface and keeps operational actions within workflows designed to handle them.
A compliance dashboard is only as useful as its numbers. Testing should therefore focus not only on whether a widget renders, but whether it reports the correct population.
For example, create a known set of customers:
Then verify that the dashboard reports exactly those numbers.
Relationship testing is also valuable. For example:
Similarly, where appropriate:
These tests help detect reporting inconsistencies that a simple UI test may miss.
Compliance teams may primarily use desktop systems, but dashboards should still behave predictably on smaller screens.
Test:
When improving an existing compliance system, not every historical record will contain the new information. Do not automatically invent missing historical values.
For example, if an older audit event recorded only:
and the system never captured the previous value, that historical entry should not be rewritten with an estimated value.
This protects the integrity of the historical compliance record.
A useful dashboard for a money transfer business could be organized into seven core areas:
Figure 1: A practical seven-area structure for a compliance dashboard in a money transfer business.
The exact structure should depend on the data and workflows available in the platform. More sections do not automatically mean a better dashboard.
A compliance dashboard should not become another page filled with numbers. The best dashboards help compliance teams answer three questions quickly.
That final question is what separates a compliance reporting dashboard from a compliance operations dashboard.
RemitSo is designed to support money transfer operations across customer management, KYC, AML controls, transaction processing, and administrative workflows. For an MTO, bringing these operational areas together makes it easier to understand where compliance-related attention may be required.
As compliance requirements and internal controls evolve, event-level and workflow-level information becomes increasingly important. A useful dashboard should therefore not simply display information collected by different modules; it should present that information in a way that supports traceability, investigation, and operational decision-making.
Explore how centralized customer, KYC, AML, transaction, and administrative workflows can provide stronger operational visibility for your money transfer business.
At a minimum, consider KYC verification status, transactions awaiting compliance review, sanctions screening activity, customer risk distribution, document expiry, compliance alerts, and actionable high-risk customer worklists where the underlying platform can reliably support those metrics.
No. A dashboard should only display metrics supported by reliable underlying data. If the platform cannot measure a particular AML event or outcome, showing a precise number can create false confidence.
Linking metrics to the underlying records creates a traceable relationship between the summary number, the relevant customer or transaction, and the investigation workflow. This makes the dashboard more useful for compliance operations.
Generally, the dashboard should act as a visibility and decision-support layer. Users should be directed to the appropriate authorised workflow to make changes so that operational actions are properly controlled and recorded.
Compliance information can be sensitive, so different users may need access to different dashboard sections. Role-based permissions allow organisations to provide appropriate visibility without giving every administrator access to the entire compliance view.
Historical records should be preserved as they were originally captured. Missing historical values should not be invented or estimated. New events can use richer structures while older records remain clearly distinguishable.
A reporting dashboard primarily summarizes information. A compliance operations dashboard goes further by connecting metrics to underlying records, prioritised worklists, and authorised workflows so users can determine what requires attention and what action should happen next.
