How to Build a Compliance Dashboard
for a Money Transfer Business

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.

What Is a Compliance Dashboard?

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.

1. Start With Compliance Questions, Not Charts

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.

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.

2. Bring KYC and Identity Verification Into View

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:

• Identity checks pending
• Verification failures
• Verification reviews
• Recently completed checks
• Documents approaching expiry

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.

3. Monitor Transactions Held for Compliance Review

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:

• Transactions currently on hold
• Pending compliance decisions
• Age of unresolved reviews
• Review status
• Relevant customer information

This turns the dashboard from a reporting page into an operational worklist.

4. Add Sanctions Screening Metrics

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:

• Customers screened
• Potential matches
• Pending reviews
• False positives
• Matches by list
• Screening outcomes

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.

5. Monitor Watchlists Without Creating Duplicate Information

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.

6. Show Customer Risk Distribution

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:

• Low risk
• Medium risk
• High risk
• Critical risk

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.

7. Build a High-Risk Customer Worklist

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.

This eliminates the need for compliance officers to manually search for the customer after identifying a risk indicator.

8. Track Expiring Identity Documents

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:

• Expiring within 7 days
• Expiring within 30 days
• Already expired

This gives the compliance team an opportunity to take action before an identity document becomes a larger operational issue.

9. Do Not Build Metrics the Platform Cannot Measure

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:

• Structuring detection
• Large cash transactions
• Internal watchlist matches
• Screening duration
• Confirmed sanctions matches

10. Avoid False Precision

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.

11. Make Every Metric Traceable

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.

12. Use Role-Based Access Control

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.

13. Load Dashboard Sections Independently

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:

1. Load KYC metrics
2. Display them
3. Load sanctions metrics
4. Display them
5. Load risk information
6. Display it
7. Continue loading additional sections as they become visible

This creates a faster perceived experience. It also means one slow query does not necessarily prevent the rest of the dashboard from becoming usable.

14. Make the Dashboard Read-Only

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.

15. Validate Dashboard Numbers With Automated Tests

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:

• 10 pending identity checks
• 5 potential sanctions matches
• 3 false positives
• 2 pending reviews

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.

16. Test Desktop and Mobile Experiences

Compliance teams may primarily use desktop systems, but dashboards should still behave predictably on smaller screens.

Test:

• Desktop layouts
• Tablet widths
• Mobile widths
• Long customer names
• Large numbers
• Empty states
• Loading states
• Error states
• Dark and light themes

17. Handle Historical Data Carefully

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.

• Preserve the original record
• Capture richer information for new events
• Clearly distinguish between old and new event structures

This protects the integrity of the historical compliance record.

18. A Practical Compliance Dashboard Structure

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.

The Goal Is Better Compliance Decisions, Not More Charts

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.

How RemitSo Approaches Compliance Visibility

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.

Frequently Asked Questions