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.

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

Re-Screening

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

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 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

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.

screening-scheduler.js

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:

{
  "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.

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

How it works:

You submit a verification for an entity.
Zenoo checks if the same entity has valid (non-expired) checks from a previous verification.
Valid checks are reused. Only expired or missing checks are run fresh.
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:

Material change of ownership

Action: New UBO, ownership restructureChecks to Run: Full Company Verification (registry + screening on new individuals)

Adverse event

Action: News article, regulatory actionChecks to Run: Screening re-run + manual review

Change of jurisdiction

Action: Company re-domiciles, individual relocatesChecks to Run: Full re-verification in new jurisdiction

Regulatory trigger

Action: New sanctions list update, regulatory directiveChecks to Run: Screening re-run on affected entities

Customer request

Action: Name change, new documentsChecks to Run: Identity re-verification

Periodic review due

Action: Scheduled review date reachedChecks to Run: Screening at minimum, full re-verification for high risk

Transaction anomaly

Action: Unusual activity flagged by your systemsChecks to Run: Screening + EDD

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

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.

batch-screening.js

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

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.

Next Review Date

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

{
  "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

review-calendar.js

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 — Screening endpoint details and match interpretation
Decision Logic — Verdict mapping and auto-approve criteria
Idempotency — Using external_reference for re-verification requests
Webhooks — Receive alerts from re-screening results

Getting Started

Use-Case Guides

Platform Concepts

Domain Concepts

Data Model

Ongoing Monitoring

Ongoing Monitoring

Re-Screening

Re-Screening Intervals

Implementing a Re-Screening Schedule

Check Validity and Expiry

Cross-Case Deduplication

What Gets Reused

Triggered Re-Verification

Batch Screening

Monitoring Alerts

Next Review Date

Building a Review Calendar

Next Steps

Getting Started

Use-Case Guides

Platform Concepts

Domain Concepts

Data Model

​Ongoing Monitoring

​Re-Screening

​Re-Screening Intervals

​Implementing a Re-Screening Schedule

​Check Validity and Expiry

​Cross-Case Deduplication

​What Gets Reused

​Triggered Re-Verification

​Batch Screening

​Monitoring Alerts

​Next Review Date

​Building a Review Calendar

​Next Steps

Ongoing Monitoring

Re-Screening

Re-Screening Intervals

Implementing a Re-Screening Schedule

Check Validity and Expiry

Cross-Case Deduplication

What Gets Reused

Triggered Re-Verification

Batch Screening

Monitoring Alerts

Next Review Date

Building a Review Calendar

Next Steps