RUI IVASS Insurance Intermediaries — Registro RUI Search, Verification & Monitoring

Search, verify, export, enrich, and monitor the RUI IVASS public register of Italian insurance intermediaries using structured data from the official IVASS open-data source.

This Actor turns the IVASS RUI register into API-ready datasets for ricerca RUI, iscritti RUI, registro RUI, batch verification, full intermediary profiles, relationships, mandates, offices, websites, and change monitoring.

If you need to consult the Registro Unico Intermediari, verify a numero iscrizione RUI, build an elenco iscritti RUI, or integrate the Italian insurance intermediary register into an automated workflow, this Actor provides structured results instead of requiring manual lookups one at a time.

What you can do

The Actor supports five operations:

Operation	Purpose
Search & bulk export	Search and filter intermediaries across the RUI and EU Annex
Batch verify	Check RUI numbers, person/company names, or websites/domains
Full profile	Build joined intermediary profiles from multiple IVASS datasets
Relationships export	Export collaborators, mandates, offices, websites, roles, and other links
Changes & monitoring	Detect changes between successive IVASS registry snapshots

All delivered results are written to the run's default Apify Dataset and can be exported or consumed through the Apify API.

---

Why use this Actor?

The public IVASS RUI portal is useful for individual consultation. This Actor is designed for workflows that need structured, repeatable, or bulk access.

Typical advantages include:

• bulk RUI IVASS search
• structured JSON output
• batch RUI verification
• RUI number normalization
• person/company lookup
• operational-status filtering
• filtering by RUI section
• regional and provincial filtering
• insurance-company mandate filtering
• website/domain lookup
• EU Annex filtering
• full profiles joined across IVASS datasets
• collaborator networks
• mandates
• offices
• websites
• corporate roles
• linked-intermediary enrichment
• persistent change monitoring
• data-quality metadata
• source and snapshot metadata
• API and automation-ready output

Typical users and workflows include:

• insurance compliance
• due diligence
• intermediary onboarding
• broker and agent verification
• insurance intelligence
• CRM enrichment
• data pipelines
• registry monitoring
• audit workflows
• AI agents requiring structured Italian insurance-register data

---

RUI IVASS search

Use Search & bulk export for a general ricerca RUI or to build a filtered list of iscritti RUI.

You can search by person/company name or leave the name empty and use filters only.

Available Search filters

• name or company name
• RUI section
• entity type
• operational status
• Italian region
• province
• insurance company / mandate
• website availability
• registration date range
• EU activity regime
• maximum number of results

Supported register sections:

• A
• B
• C
• D
• E
• F
• EU Annex

Province filters accept either the province name or abbreviation.

For example:

Roma
RM

When region and province are supplied together, they must match compatible geographic information from the same office record.

Search example

{
  "mode": "search",
  "nameQuery": "ROSSI",
  "sections": ["A", "B"],
  "entityType": "person",
  "operationalStatus": "operational",
  "regions": ["Lombardia"],
  "provinces": ["MI"],
  "hasWebsite": "any",
  "maxResults": 100,
  "includeDataQuality": true,
  "includeSourceMetadata": true
}

Search output

Search produces records with:

{
  "recordType": "intermediary",
  "ruiNumber": "E000123456",
  "section": "E",
  "entityType": "person",
  "operational": true,
  "registrationDate": "2025-01-28",
  "person": {},
  "company": null,
  "counts": {},
  "dataQuality": {},
  "source": {}
}

The values above illustrate the output structure and are not intended to represent a guaranteed current RUI record.

---

Batch RUI verification

Use Batch verify when you already have values that need to be checked against the current IVASS registry.

Supported verification methods:

1. RUI number
2. Person or company name
3. Website or domain

Multiple values can be checked in one run.

Verify a numero iscrizione RUI

{
  "mode": "verify",
  "verificationType": "rui_number",
  "verificationValues": [
    "E000769268",
    "E000-745304"
  ]
}

User-supplied RUI numbers are normalized for matching without rewriting the underlying source records.

Possible match statuses include:

exact_unique
exact_multiple
partial
not_found
invalid_input

If a RUI number is associated with multiple source records, the Actor does not arbitrarily select one of them.

Instead, it reports the ambiguity.

Verify by name

{
  "mode": "verify",
  "verificationType": "name",
  "verificationValues": [
    "ROSSI MARIO"
  ],
  "nameMatchMode": "exact_then_partial"
}

Available matching modes:

exact_only
exact_then_partial

When enabled, partial candidates can be returned when an appropriate exact match is not available.

Verify website or domain

{
  "mode": "verify",
  "verificationType": "domain",
  "verificationValues": [
    "example.it"
  ]
}

A website or domain may be connected to more than one intermediary.

This is particularly relevant for insurance networks using shared domains or subdomains.

The Actor preserves the distinct intermediary matches instead of assuming that a shared website belongs to only one RUI record.

Verification output

{
  "recordType": "verification",
  "verificationType": "rui_number",
  "inputValue": "E000769268",
  "normalizedInput": "E000769268",
  "matchStatus": "exact_unique",
  "matchCount": 1,
  "matches": [],
  "dataQuality": {},
  "source": {}
}

---

Full intermediary profiles

Use Full profile when you want more than a basic registro RUI lookup.

This operation joins the selected RUI number with compatible information from the other IVASS datasets.

Depending on the intermediary and available source data, a profile can include:

• intermediary identity
• registration information
• operational status
• EU Annex information
• offices
• websites
• insurance-company mandates
• corporate roles
• first-level collaborations
• second-level collaborations
• accessory intermediary records
• Section D distribution responsibles
• non-standard product agents
• data-quality metadata
• source metadata

Full Profile example

{
  "mode": "full_profile",
  "profileRuiNumbers": [
    "UE00010496"
  ],
  "includeCollaboratorsInProfile": false,
  "includeDataQuality": true,
  "includeSourceMetadata": true
}

Embedding collaborators

To include complete collaborator relationships inside a profile:

{
  "includeCollaboratorsInProfile": true
}

Some intermediary networks can contain thousands of collaboration records.

For large networks, Relationships export is generally preferable because relationships are returned as individual Dataset items instead of creating one very large profile.

A payload-safety guard is also applied to unusually large Full Profile results.

---

RUI relationships export

Use Relationships export to extract individual relationships from the IVASS datasets.

Supported relationship types are:

collaborations
accessory_intermediaries
offices
websites
mandates
corporate_roles
section_d_responsibles
non_standard_product_agents

You can limit results to selected RUI numbers or export compatible relationships across the registry.

Both first- and second-level collaborations are supported.

Relationships example

{
  "mode": "relationships",
  "relationshipTypes": [
    "collaborations",
    "mandates",
    "websites"
  ],
  "relationshipRuiNumbers": [
    "A000006378"
  ],
  "collaborationLevels": [
    "1",
    "2"
  ],
  "includeLinkedIntermediaryDetails": true,
  "maxResults": 100,
  "includeDataQuality": true,
  "includeSourceMetadata": true
}

Linked intermediary enrichment

With:

{
  "includeLinkedIntermediaryDetails": true
}

the Actor attempts to add current identity and status information for RUI numbers referenced by the relationship.

If a referenced RUI number cannot be found in the current intermediary dataset, it is not silently discarded.

The condition can instead be reported through dataQuality.

Duplicate linked RUI situations are also preserved rather than arbitrarily resolved.

Relationship output

{
  "recordType": "relationship",
  "relationshipType": "collaborations",
  "sourceTable": "ELENCO_COLLABORATORI.csv",
  "ruiNumbers": [],
  "matchedFilterRuiNumbers": [],
  "relationship": {},
  "linkedIntermediaries": [],
  "dataQuality": {},
  "source": {}
}

---

Changes & RUI monitoring

Use Changes & monitoring when you need to know what changed in the IVASS RUI register between snapshots.

The Actor maintains a persistent baseline and compares a new valid registry snapshot against the previous baseline.

Supported change types:

INTERMEDIARY_ADDED
INTERMEDIARY_REMOVED
STATUS_CHANGED
WEBSITE_ADDED
WEBSITE_REMOVED
OFFICE_ADDED
OFFICE_REMOVED
MANDATE_ADDED
MANDATE_REMOVED
COLLABORATOR_ADDED
COLLABORATOR_REMOVED
ROLE_ADDED
ROLE_REMOVED
RESPONSIBLE_D_CHANGED

Monitoring example

{
  "mode": "changes",
  "changeTypes": [
    "INTERMEDIARY_ADDED",
    "INTERMEDIARY_REMOVED",
    "STATUS_CHANGED"
  ],
  "historyNamespace": "my-monitor",
  "updateBaseline": true,
  "maxResults": 100,
  "includeDataQuality": true,
  "includeSourceMetadata": true
}

How the monitoring baseline works

For a new historyNamespace:

1. the first successful run initializes the baseline
2. no historical changes are invented before that baseline
3. a later run compares the current valid IVASS snapshot with the stored baseline
4. detected differences are returned as change records
5. if updateBaseline is enabled, the current snapshot becomes the new baseline

Independent monitoring histories

Different namespaces can maintain independent monitoring histories.

For example:

compliance-team
broker-network-a
daily-monitor

Use the same namespace across successive runs when those runs should belong to the same monitoring history.

---

Official IVASS source

The Actor processes the public open-data export made available by IVASS — Istituto per la Vigilanza sulle Assicurazioni.

At the beginning of a run, the Actor downloads the current available RUI archive and validates the expected source structure before producing results.

The source currently contains data used for:

• intermediaries
• collaborators
• accessory intermediaries
• mandates
• offices
• websites
• corporate roles
• Section D distribution responsibles
• non-standard product agents

The Actor does not depend on undocumented private APIs for its core registry dataset.

Where enabled, output records include metadata such as:

{
  "source": {
    "provider": "IVASS",
    "dataset": "RUI",
    "snapshotDate": "2026-08-19",
    "retrievedAt": "2026-08-19T20:39:29Z",
    "sourceUrl": "https://ruipubblico.ivass.it/inquiry-public-manager/inquiry-public/esporta-registro"
  }
}

The date above is an example.

Actual results contain metadata for the source snapshot processed by that run.

---

Dataset output

All delivered results are stored in the default Apify Dataset.

The Actor provides five Dataset views:

Operation	Dataset view	recordType
Search	Search results	intermediary
Batch verify	Verification results	verification
Full profile	Full profiles	full_profile
Relationships	Relationships	relationship
Changes	Registry changes	change

Because all five operations share one Dataset schema, Apify may initially display the first configured view, Search results.

If you ran a different operation, switch to its corresponding view.

The complete raw record is also available through All fields, JSON output, exports, and the Dataset API.

---

Data quality and ambiguity handling

Public registry data can contain anomalies such as:

• duplicate RUI numbers
• ambiguous names
• malformed source rows
• unusual dates
• references to RUI numbers not present in the primary intermediary dataset

The Actor follows a conservative rule:

Preserve the source whenever possible, do not invent missing information, and report ambiguity instead of silently resolving it.

Depending on the operation, dataQuality can identify conditions such as:

• duplicate RUI numbers
• multiple exact matches
• input normalization
• recovered malformed rows
• suspicious dates
• orphan RUI references
• duplicate linked references
• ambiguous name matches

The Actor validates the archive and expected CSV headers before processing.

If the upstream IVASS structure changes incompatibly, failing clearly is preferable to silently returning unreliable data.

---

Pay Per Event pricing

This Actor uses Pay Per Event (PPE) pricing.

Current configured prices are:

Event	Price
Actor Start	$0.03 / run
Search result	$0.0005 / delivered result
Verification result	$0.001 / verification billing unit
Full profile	$0.01 / delivered profile
Relationship result	$0.0005 / delivered relationship
Change result	$0.002 / delivered change

Always check the current Pricing section on the Actor page before running it, as published pricing may change in the future.

Cost examples

100 Search results

Actor Start                 $0.030
100 × Search result         $0.050
---------------------------------
Total                       $0.080

1 Full Profile

Actor Start                 $0.030
1 × Full profile            $0.010
---------------------------------
Total                       $0.040

100 Relationships

Actor Start                 $0.030
100 × Relationship result   $0.050
---------------------------------
Total                       $0.080

10 detected changes

Actor Start                 $0.030
10 × Change result          $0.020
---------------------------------
Total                       $0.050

---

Batch Verify billing

Verification billing is based on intermediary matches actually delivered.

For example:

1 intermediary match   → 1 verification billing unit
2 intermediary matches → 2 verification billing units
10 matches             → 10 verification billing units

A delivered not_found verification uses a minimum of one billing unit.

This matters for shared websites and domains.

A domain used by hundreds of intermediaries can produce hundreds of intermediary matches and is therefore not billed as one inexpensive lookup while delivering hundreds of matching entities.

Billing is based on delivered intermediary matches rather than the number of underlying technical website rows.

---

Maximum cost per run

Apify's Maximum cost per run setting can be used to cap spending.

The Actor checks the remaining Pay Per Event budget before delivering a chargeable result.

For multi-match verification results, delivery is atomic:

• a result is not partially delivered
• individual matches are not cut off simply to fit the remaining budget
• if the remaining run budget cannot cover the complete verification result, that result is skipped
• the verification event is not charged for a result that was not delivered

This is particularly useful for domain verification, where a shared domain may unexpectedly match a large number of intermediaries.

---

maxResults

maxResults controls the maximum number of Dataset items returned where applicable.

It applies to:

• Search
• Relationships
• Changes

Example:

{
  "maxResults": 100
}

Set:

{
  "maxResults": 0
}

to request all matching results.

Larger outputs can increase Pay Per Event charges.

maxResults does not replace source validation: the Actor still processes and validates the current registry source before delivering matching output.

Batch Verify and Full Profile are primarily controlled by their dedicated input lists.

---

RUI API and automation

The Actor can be run manually from Apify Console or integrated into automated workflows.

Typical uses include:

• RUI IVASS API workflows
• IVASS RUI search integrations
• RUI number checker
• intermediary verification
• scheduled registry checks
• CRM enrichment
• insurance intermediary onboarding
• compliance pipelines
• ETL jobs
• Make integrations
• Zapier integrations
• AI-agent tools
• structured insurance-register datasets

Python API example

from apify_client import ApifyClient

client = ApifyClient("<APIFY_API_TOKEN>")

run = client.actor(
    "beyondforge/rui-ivass-insurance-intermediaries"
).call(
    run_input={
        "mode": "verify",
        "verificationType": "rui_number",
        "verificationValues": [
            "E000769268"
        ],
        "includeDataQuality": True,
        "includeSourceMetadata": True
    }
)

items = client.dataset(
    run["defaultDatasetId"]
).list_items().items

for item in items:
    print(item)

You can also use the API button in Apify Console to generate API request examples.

---

AI agent discovery

The Actor exposes explicit operation names, predictable Dataset record types, and structured results suitable for automated tools and AI agents.

It can be used when an agent needs to:

• search the Italian insurance intermediary register
• perform a RUI register search
• check a RUI number
• verify whether a name appears in the current RUI data
• perform insurance intermediary verification
• inspect website/domain associations
• distinguish unique, multiple, partial, and missing matches
• retrieve complete intermediary profiles
• inspect insurance distribution relationships
• monitor registry changes
• consume source and data-quality metadata

Relevant concepts include:

RUI IVASS
IVASS RUI
Italian insurance intermediary register
RUI register search
RUI number checker
insurance intermediary checker
insurance intermediary verification
registered insurance intermediary lookup
Italian insurance register API
RUI API
RUI monitoring
insurance compliance data

---

Common use cases

Cerca iscritti RUI

Use Search to find persons or companies in the current register by name or filters.

It can also be used to build a targeted elenco iscritti RUI instead of checking records manually one at a time.

Registro RUI / Registro Unico Intermediari

Use Search & bulk export to query the register using structured filters and retrieve machine-readable output.

Verifica iscrizione RUI

Use Batch Verify with verificationType = rui_number to check one or more registration numbers against the current source snapshot.

Numero iscrizione RUI checker

Submit known RUI numbers in bulk and receive a structured match status for each supplied value.

Insurance intermediary checker

Use Batch Verify by RUI number, name, or domain to identify matching intermediary records.

Broker and agent due diligence

Use registration information together with current operational status, source metadata, mandates, websites, and relationships.

CRM enrichment

Add RUI data, websites, offices, mandates, and related information to an existing CRM or business dataset.

Website/domain verification

Check whether a domain appears in the IVASS website dataset and identify the RUI intermediaries associated with it.

Insurance intelligence

Build structured datasets of intermediaries, relationships, mandates, websites, offices, and related insurance-distribution information.

RUI change monitoring

Detect intermediary additions or removals, operational-status changes, and changes to websites, offices, mandates, collaborators, roles, and Section D responsibles.

---

FAQ

What is RUI IVASS?

RUI is the Italian register used by IVASS for insurance-intermediary information.

This Actor processes the public IVASS RUI open-data source and converts it into structured Dataset records.

Is “IVASS RUI” the same register?

Users commonly search for the register using terms such as RUI IVASS, IVASS RUI, registro RUI, and registro IVASS.

This Actor is specifically designed around the public IVASS RUI data source.

Can I perform a ricerca RUI by name?

Yes.

Select Search & bulk export and enter a person or company name.

You can combine the name with filters such as section, operational status, region, province, mandate, website availability, registration dates, or EU activity regime.

Can I get an elenco iscritti RUI?

Yes.

Leave the name empty and use Search filters to build a targeted set of intermediaries.

Set an appropriate maxResults value according to the size of the export you need.

Can I verify an iscrizione RUI?

Yes.

Use Batch verify with:

Verification type: RUI number

and provide one or more registration numbers.

Can I check a numero iscrizione RUI?

Yes.

The supplied number is normalized for matching, and the result reports whether there is a unique match, multiple matches, or no match in the current source snapshot.

Can I search the registro intermediari assicurativi by region or province?

Yes, where compatible office/location information is available in the IVASS source data.

Both Italian region and province filters are supported.

Can I search by insurance company?

Search can filter intermediaries using insurance-company names or codes represented in the mandates dataset.

Can I verify a broker or insurance agent?

The Actor can search and verify intermediary records present in the IVASS source.

It does not independently issue an authorization or regulatory certification.

Can I verify an insurance website?

You can use Batch Verify with verificationType = domain.

The Actor checks the domain against website information contained in the IVASS dataset and returns the distinct linked intermediary matches.

Can one domain match many RUI intermediaries?

Yes.

Insurance groups and networks may use a shared domain or subdomain across many intermediaries.

The Actor preserves all distinct matched intermediaries.

Can one RUI number have multiple records?

Yes, duplicate RUI-number situations can exist in the source.

The Actor reports these as multiple matches instead of choosing one source record arbitrarily.

Does the Actor support EU intermediaries?

Yes.

Search supports the EU Annex as well as EU activity regimes represented in the source data.

Can I export the results?

Yes.

Results are stored in the default Apify Dataset and can be retrieved through Apify exports, API calls, or integrations.

Why did my first Changes & monitoring run return no changes?

A new monitoring namespace has no previous baseline.

The first successful run initializes that baseline.

Later runs can detect differences between the stored baseline and newer valid IVASS snapshots.

Does monitoring provide the complete historical RUI archive?

No.

Changes & monitoring detects changes from the stored baseline forward.

It does not reconstruct historical changes from periods before the baseline existed.

Which Dataset view should I use?

Use the view corresponding to the selected operation:

Search            → Search results
Batch verify      → Verification results
Full profile      → Full profiles
Relationships     → Relationships
Changes           → Registry changes

If Apify initially opens Search results after another operation, switch manually to the corresponding view.

---

Important limitations and disclaimer

Independent tool

This Actor is an independent data-processing product.

It is not IVASS, is not affiliated with IVASS, and does not issue official registrations, certificates, authorizations, regulatory decisions, or legal opinions.

For authoritative regulatory or legal decisions, consult IVASS and the applicable regulations directly.

Source freshness

Results reflect the IVASS source snapshot available when the run downloads the registry archive.

Source metadata can be included so that downstream systems know which snapshot produced the result.

No invented corrections

The Actor does not silently rewrite ambiguous or duplicate source information.

When a condition can be identified reliably, it is reported through match status or dataQuality.

Missing related data

Not every intermediary has every relationship type.

A record can legitimately have no:

• website
• mandate
• office matching a particular geography
• corporate role
• collaboration
• accessory record

The absence of one of these related records does not by itself mean that the intermediary record is invalid.

Monitoring is baseline-based

Change monitoring begins when a baseline is created for a namespace.

It is not a substitute for a complete historical archive of the register.

---

Reliability and responsible processing

The Actor is designed around deterministic and transparent processing.

Core principles include:

• use the public IVASS open-data registry source
• validate the downloaded archive
• validate expected CSV structure
• avoid inventing missing values
• preserve ambiguous and duplicate source conditions
• normalize user inputs without rewriting source records
• expose data-quality information
• include source and snapshot metadata when requested
• charge Pay Per Event only for results actually delivered
• respect Maximum cost per run before delivery
• avoid partial multi-match verification delivery

---

Support

If you encounter an unexpected result, open an issue on the Actor page.

For faster troubleshooting, include:

• selected Operation
• relevant input values
• Apify Run ID
• expected behavior
• actual result

Do not publish API tokens, credentials, or other secrets in an issue.

---

Built for structured RUI data

RUI IVASS Insurance Intermediaries is built for users who need more than a manual RUI consultation.

Use it for RUI IVASS search, IVASS RUI verification, iscritti RUI, registro RUI exports, ricerca RUI, RUI number checking, full profiles, relationship data, change monitoring, APIs, automation, compliance workflows, and machine-readable Italian insurance-intermediary data.