> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zenoo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ongoing Monitoring

> Implement periodic re-screening, check expiry management, and triggered re-verification for ongoing compliance.

# Ongoing Monitoring

Verification is not a one-time event. Regulatory requirements mandate periodic re-screening, check expiry management, and triggered re-verification when circumstances change.

<Warning>
  Regulatory requirements mandate periodic re-screening. Failure to re-screen customers at appropriate intervals can result in regulatory penalties and compliance failures.
</Warning>

## Re-Screening

Use the standalone screening endpoint to re-screen existing customers against PEP, sanctions, adverse media, and watchlist databases.

```bash theme={null}
curl -X POST \
  "https://instance.prod.onboardapp.io/api/gateway/execute/{project_hash}/screening/api" \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: your-api-key" \
  -H "X-SYNC-TIMEOUT: 30000" \
  -d '{
    "name": "Jane Smith",
    "date_of_birth": "1990-06-15",
    "country": "GB",
    "entity_type": "person",
    "categories": ["pep", "sanctions", "adverse_media", "watchlist"],
    "external_reference": "REVIEW-CUST-1234-2026Q1"
  }'
```

Re-screening uses the same endpoint and response format as initial screening. See the [Screening Quickstart](/use-cases/screening) for full request and response details.

## Re-Screening Intervals

Schedule re-screening frequency based on the customer's risk tier:

| Risk Tier  | Recommended Interval | Rationale                                                                           |
| ---------- | -------------------- | ----------------------------------------------------------------------------------- |
| **High**   | Every 6 months       | Highest regulatory scrutiny. Frequent changes in sanctions lists and PEP databases. |
| **Medium** | Every 12 months      | Standard CDD cycle. Aligns with most regulatory frameworks.                         |
| **Low**    | Every 24 months      | Reduced frequency appropriate for low-risk customers with stable profiles.          |

These intervals are recommendations. Your compliance program may require different schedules based on jurisdiction, customer type, or regulatory guidance.

### Implementing a Re-Screening Schedule

<Tip>
  Implement a review calendar that automatically schedules re-screening based on the risk tier returned in the compliance report. Use the `next_review_date` field from the compliance metadata to track when each customer is due.
</Tip>

```javascript screening-scheduler.js theme={null}
async function scheduleReScreening(customerId, riskTier) {
  const intervals = {
    High: 6, // months
    Medium: 12,
    Low: 24
  };

  const months = intervals[riskTier] || 12;
  const nextReviewDate = new Date();
  nextReviewDate.setMonth(nextReviewDate.getMonth() + months);

  await db.customers.update(customerId, {
    next_screening_date: nextReviewDate,
    risk_tier: riskTier
  });
}

// Run daily: find customers due for re-screening
async function processScheduledScreenings() {
  const due = await db.customers.find({
    next_screening_date: { $lte: new Date() },
    status: "active"
  });

  for (const customer of due) {
    await submitScreening(customer);
  }
}
```

## Check Validity and Expiry

Verification checks have defined validity periods. After a check expires, it should be re-run before relying on its results.

| Check Category | Validity Period | Rationale                                                         |
| -------------- | --------------- | ----------------------------------------------------------------- |
| **Identity**   | 365 days        | Identity documents and database records are relatively stable     |
| **Screening**  | 90 days         | PEP, sanctions, and adverse media databases update frequently     |
| **Company**    | 180 days        | Company registry data changes with filings, director appointments |
| **Financial**  | 365 days        | Financial records change annually with audits                     |
| **EDD**        | 180 days        | Enhanced due diligence findings may become stale quickly          |

Zenoo tracks check expiry dates internally. The compliance report includes validity information for each check:

```json theme={null}
{
  "checks_summary": {
    "checks": [
      {
        "type": "Company Screening",
        "status": "Pass",
        "completed_at": "2026-01-15T14:30:20Z",
        "valid_until": "2026-04-15T14:30:20Z"
      },
      {
        "type": "Company Registration",
        "status": "Pass",
        "completed_at": "2026-01-15T14:30:15Z",
        "valid_until": "2026-07-15T14:30:15Z"
      }
    ]
  }
}
```

Use the `valid_until` field to schedule check renewal before expiry.

## Cross-Case Deduplication

When running a new verification on an entity that has been verified before, Zenoo automatically evaluates whether existing checks are still valid.

<Note>
  You are not charged for reused checks. Zenoo automatically deduplicates checks across cases, so you only pay for checks that are actually executed.
</Note>

**How it works:**

1. You submit a verification for an entity.
2. Zenoo checks if the same entity has valid (non-expired) checks from a previous verification.
3. Valid checks are reused. Only expired or missing checks are run fresh.
4. Reused checks are marked with their original source case for audit traceability.

This means:

* You are not charged for reused checks.
* Results are returned faster (reused checks are instant).
* Audit trail shows the provenance of each check.

Cross-case deduplication is automatic. You do not need to implement any special logic. Just submit verifications as normal.

### What Gets Reused

| Check Type              | Reuse Eligible | Condition                                     |
| ----------------------- | -------------- | --------------------------------------------- |
| Company Registration    | Yes            | Within validity period                        |
| PEP/Sanctions Screening | Yes            | Within 90-day validity                        |
| Identity Verification   | Yes            | Within 365-day validity                       |
| Document Verification   | Yes            | Within 365-day validity, document not expired |
| Financial Checks        | Yes            | Within 365-day validity                       |
| Biometric Liveness      | No             | Always re-run (presence must be current)      |

## Triggered Re-Verification

Beyond scheduled re-screening, certain events should trigger an immediate re-verification:

<AccordionGroup>
  <Accordion title="Material change of ownership">
    **Action:** New UBO, ownership restructure

    **Checks to Run:** Full Company Verification (registry + screening on new individuals)
  </Accordion>

  <Accordion title="Adverse event">
    **Action:** News article, regulatory action

    **Checks to Run:** Screening re-run + manual review
  </Accordion>

  <Accordion title="Change of jurisdiction">
    **Action:** Company re-domiciles, individual relocates

    **Checks to Run:** Full re-verification in new jurisdiction
  </Accordion>

  <Accordion title="Regulatory trigger">
    **Action:** New sanctions list update, regulatory directive

    **Checks to Run:** Screening re-run on affected entities
  </Accordion>

  <Accordion title="Customer request">
    **Action:** Name change, new documents

    **Checks to Run:** Identity re-verification
  </Accordion>

  <Accordion title="Periodic review due">
    **Action:** Scheduled review date reached

    **Checks to Run:** Screening at minimum, full re-verification for high risk
  </Accordion>

  <Accordion title="Transaction anomaly">
    **Action:** Unusual activity flagged by your systems

    **Checks to Run:** Screening + EDD
  </Accordion>
</AccordionGroup>

For triggered re-verification, submit a new verification request with a new `external_reference` that reflects the trigger:

```bash theme={null}
curl -X POST \
  "https://instance.prod.onboardapp.io/api/gateway/execute/{project_hash}/api" \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: your-api-key" \
  -H "X-SYNC-TIMEOUT: 30000" \
  -d '{
    "company_name": "Acme Holdings Ltd",
    "registration_number": "12345678",
    "country": "GB",
    "external_reference": "TRIGGER-ADVERSE-ACME-2026-0215"
  }'
```

## Batch Screening

For ongoing monitoring of your entire customer base, submit multiple entities to the screening endpoint. Each request screens one entity, but you can submit many requests in parallel.

```javascript batch-screening.js theme={null}
async function batchScreen(customers) {
  const CONCURRENCY = 10; // respect rate limits
  const results = [];

  for (let i = 0; i < customers.length; i += CONCURRENCY) {
    const batch = customers.slice(i, i + CONCURRENCY);

    const batchResults = await Promise.all(
      batch.map((customer) =>
        screenEntity({
          name: customer.name,
          date_of_birth: customer.dob,
          country: customer.country,
          entity_type: customer.type,
          categories: ["pep", "sanctions", "adverse_media", "watchlist"],
          external_reference: `BATCH-${customer.id}-${Date.now()}`
        })
      )
    );

    results.push(...batchResults);

    // Respect rate limits between batches
    if (i + CONCURRENCY < customers.length) {
      await sleep(1000);
    }
  }

  return results;
}
```

Monitor your rate limits when running batch operations. Contact Zenoo to request higher limits for large batch runs.

## Monitoring Alerts

When re-screening returns new matches, Zenoo generates alerts in the case management system:

| Alert Type    | Trigger                                  | Severity                                 |
| ------------- | ---------------------------------------- | ---------------------------------------- |
| PEP Match     | Entity newly appears in a PEP database   | Medium (Class 3-4) or High (Class 1-2)   |
| Sanctions Hit | Entity newly appears on a sanctions list | Critical. Immediate escalation required. |
| Adverse Media | New negative media articles found        | Medium. Manual review required.          |
| Status Change | Previously clear entity now has matches  | Depends on match type                    |

<Info>
  New matches found during re-screening are compared against the previous screening results. Only genuinely new matches generate alerts, not previously reviewed and dismissed matches.
</Info>

## Next Review Date

The compliance report includes a recommended next review date based on the customer's risk tier:

```json theme={null}
{
  "compliance_metadata": {
    "cdd_completed": true,
    "cdd_completed_at": "2026-01-15T14:32:00Z",
    "next_review_date": "2026-07-15",
    "risk_tier": "High",
    "edd_required": false
  }
}
```

Use the `next_review_date` field to schedule the next periodic review in your system. This date is calculated based on the risk tier using the intervals in the re-screening table above.

### Building a Review Calendar

```javascript review-calendar.js theme={null}
async function processCompletedVerification(result) {
  const { case_reference, compliance_metadata } = result;

  // Store review date from the compliance report
  await db.reviews.create({
    case_reference,
    customer_id: result.external_reference,
    completed_at: compliance_metadata.cdd_completed_at,
    next_review: compliance_metadata.next_review_date,
    risk_tier: compliance_metadata.risk_tier
  });

  // Schedule a reminder 30 days before review is due
  const reminderDate = new Date(compliance_metadata.next_review_date);
  reminderDate.setDate(reminderDate.getDate() - 30);

  await scheduler.schedule(reminderDate, "review-reminder", {
    case_reference,
    customer_id: result.external_reference
  });
}
```

## Next Steps

* [Screening Quickstart](/use-cases/screening) -- Screening endpoint details and match interpretation
* [Decision Logic](/use-cases/kyb-verification) -- Verdict mapping and auto-approve criteria
* [Idempotency](/guides/idempotency) -- Using external\_reference for re-verification requests
* [Webhooks](/guides/webhooks) -- Receive alerts from re-screening results