Import your Customer Portfolio

If you’re switching to RiskOS™ from another provider, you’ll likely need to import your existing customer base so they can be monitored against watchlists without requiring every customer to re-onboard. This process is called a portfolio import.

Why portfolio imports matter

• Reduce noise: if you already reviewed customers with your old provider, you don’t want duplicate alerts for the same cleared entities.
• Enable monitoring: once imported, your customers can be automatically monitored for new sanctions, updates, or removals.

How portfolio import works in RiskOS™

• RiskOS™ supports imports through Batch Jobs.
• You prepare a CSV file with one row per customer.
• Each row includes your internal reference ID plus flags for accept list and monitoring.
• You upload the file via the RiskOS™ dashboard or the Batch Jobs API.
• RiskOS™ processes the file, assigns a Batch Job ID, and enrolls customers accordingly.

Portfolio import file structure

Your CSV must include the following columns:

transactionId

• Required. This is your internal reference ID for the customer.
• Used to tie back alerts to your system.

acceptList (true / false)

• If true, tells RiskOS™ to suppress alerts for historical matches you’ve already reviewed.
• Future matches on new entities will still trigger alerts.

autoMonitoring (true / false)

• If true, automatically enrolls the customer into monitoring once imported.
• If false, the customer is not monitored until you manually enroll them.

📘

Note:

File size limit: 512 MB per CSV upload. Split larger portfolios into multiple files.

Uploading the CSV

1. Log into the RiskOS™ dashboard.
2. Go to Transactions → Batch Jobs → New Batch Job.
3. Select Watchlist Portfolio Scrub.
4. Upload your CSV.
5. Confirm encryption requirements if applicable.
6. Submit.

Processing and results

• After upload, RiskOS™ assigns a Batch Job ID.
• You can query this ID to check processing status.
• Once complete, customers are imported:
  • Those with autoMonitoring: true will generate new alerts if they are added, removed, or updated on a watchlist in the future.
  • Those with acceptList: true won’t trigger duplicate alerts for previously cleared entities.

Best practices

• Always include acceptList flags: prevents flooding your compliance team with duplicate alerts when migrating from an old provider.
• Encrypt CSV files: follow your org’s data security requirements when uploading sensitive customer identifiers.
• Test with a small file first: use a handful of sample rows to validate that jobs process correctly before uploading your entire portfolio.
• Track Batch Job IDs: keep them in your logs for troubleshooting or audits.

Accept lists / suppressing alerts

When you screen or monitor customers, you’ll often see repeat alerts for the same entity. For example:

• You screened someone last month, got a possible match, your compliance team reviewed it, and decided it was a false positive. If you mark it as a false positive in RiskOS™, your team will no longer receive the same listed entity as a match for future monitoring events.
• If you’re not using the RiskOS™ dashboard to mark these alerts as false positives, every time you rescreen or as lists update, RiskOS™ will keep alerting you about that same entity again.

Accept lists solve this problem. They let you tell RiskOS™ via API:

“I’ve already reviewed this match and accepted the risk. Don’t show me this same match for this entity again, but keep monitoring for new matches.”

What accept lists do

Accept lists are a filter, not a kill switch. They prevent duplicate alerts for entities your compliance team already cleared, but they don’t stop RiskOS™ from monitoring for new risk events.

They help to:

• Reduce noise — stops duplicate cases for the same previously cleared entity.
• Save analyst time — compliance teams don’t want to keep reviewing the same false positive.
• Keep you compliant — monitoring continues; new matches on other entities will still trigger alerts.

How it works

When you screen an identity, RiskOS™ returns a set of candidate matches:

• If a candidate is a true positive, you’ll mark it as such in your case management system or RiskOS™. You’ll continue to receive updates (additions, changes, or removals) for that entity going forward.
• If a candidate is a false positive, you can add it to your accept list. This tells the system to suppress future alerts tied to that same entity for this customer.

Key points:

• Accepted entities won’t trigger new events unless something materially changes (e.g., new date of birth or a newly discovered middle name). These updates can shift the match confidence or risk posture, so we surface them to help you reassess.
• Even when alerts are suppressed, they’re still logged and available for audit.

How to enable accept lists

There are two ways to use accept lists:

1. Inline flag in screening requests

When you call the /api/evaluation endpoint, include an accept_list flag inside additional_context:

"data": {
  "individual": {
    "given_name": "Amir",
    "family_name": "Chen",
    "additional_context": {
      "accept_list": true,
      "notes": "Reviewed on 2025-08-18, confirmed false positive"
    }
  }
}

• accept_list: true → suppresses repeat alerts for that entity.
• notes → optional, but useful for storing audit comments.

2. Bulk upload via Batch Jobs

If you’re migrating a portfolio or need to suppress alerts for many customers at once:

1. Create a CSV file with one row per customer.
2. Include an acceptList column (true/false).
3. Upload via Batch Jobs in the RiskOS™ dashboard or API.