## 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`:

JSON  
```json  
"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.