A Monitoring Profile establishes the specific data fields within a given data layer that should be monitored, and the conditions under which a change event should be triggered.

There are no fees involved with establishing Monitoring Profiles, and customers may create as many profiles as needed.

A User Preference captures the technical details required to deliver information through various protocols, including Email and HTTP Callback.

User Preferences are created/maintained through the User Service.

A Notification Profile establishes the protocol by which change events should be delivered to customers, and references user preferences setup in the User Service. This is the PUSH component of the Data Field Monitoring feature.

There are no fees involved with establishing Notification Profiles, and customers may create as many profiles as needed.

The Monitoring Registration combines Monitoring and Notification Profiles with a specific D-U-N-S Number and initiates the Data Field Monitoring process. There are two levels of monitoring: change events only, or events with data layer included.

Fees are incurred only when a Monitoring Registration is created and/or upon contract renewal (if the auto-renew option is active).

Here are a couple of things to be aware of when monitoring a data layer, an aggregate within a data layer, or specific fields within a data layer:

• The monitoring service will trigger notices whenever the values of fields (as defined by the Monitoring profile) change. This may include the first time the field has a value (NewlyAdded), when it no longer has a value (Dropped), or the value has been modified (ValueChanged).
• The monitoring change notice may include "changes" for items that fall within the definition of the Monitoring profile, but did not change (No Change). For example, if the MailingAddess is monitored, and the street address changes, but the city and state do not, the change notice will include entries for the city and state.
• When the condition is ValueChanged or Dropped, the change notice will also include the previous value.
• When there are multiple occurrences of a field, the sequence will be incorporated into the XPATH (e.g. "/PrimaryAddress[1]/").
• Multiple change events for a D-U-N-S Number may be clustered into a single change notice when delivered to customer (i.e. PUSH), whereas, they will be separate when using the ListChangeNotice function (i.e. PULL).

Example #1: CEO Change

Company XYZ announces a new CEO: John Smith is replaced by Edward Jones. The business element for the CEO name is Most Senior Principal Full Name. It is part of an aggregate XPATH, therefore all elements of the aggregate will be included in the change notice.

In the change notice, the following items should be examined:

• SubjectHeader will equal D-U-N-S Number of company XYZ,
• Multiple elements will be delivered in the change event.
• The attributes on the element explain the change that has occurred.
• The outer PCMElementXPATHText represents the aggregate.
• The inner (attribute) PCMElementXPATHText represents the business element(s).

<ChangeEvent>

<PCMElementXPATHText>//Organization/PrincipalsAndManagement/MostSeniorPrincipal/</PCMElementXPATHText>

<Element ChangeType="ValueChanged" OldValue="John Smith" PCMElementXPATHText="//Organization/PrincipalsAndManagement/MostSeniorPrincipal/PrincipalName/FullName">Edward Jones</Element>

{ all other aggregate elements will be included here }

</ChangeEvent>

Example #2: Change of Address

Company XYZ announces it's headquarters have moved within New York City from 123 E 81st Street, Suite 400 to 200 Park Avenue. These business elements are part of an aggregate. The street address will change, and the suite portion will be dropped. The city and state will be included and reflect no change.

In the change notice, the following items should be examined:

• SubjectHeader will equal D-U-N-S Number of company XYZ,
• One or more elements will be delivered in the change event.
• The attributes on the element explain the change that has occurred.
• The outer PCMElementXPATHText represents the aggregate.
• The inner (attribute) PCMElementXPATHText represents the business element(s).

<ChangeEvent>

<PCMElementXPATHText>//Organization/Location/PrimaryAddress</PCMElementXPATHText>

<Element ChangeType="ValueChanged" OldValue="123 E 81st Street" PCMElementXPATHText="//Organization/Location/PrimaryAddress[1]/StreetAddressLine[1]/LineText">200 Park Avenue</Element>

<Element ChangeType="Dropped" OldValue="Suite 400" PCMElementXPATHText="//Organization/Location/PrimaryAddress[1]/StreetAddressLine[2]/LineText" />

<Element ChangeType="NoChange" PCMElementXPATHText="//Organization/Location/PrimaryAddress[1]/PrimaryTownName">New York</Element>

<Element ChangeType="NoChange" PCMElementXPATHText="//Organization/Location/PrimaryAddress[1]/TerritoryAbbreviatedName">NY</Element>

</ChangeEvent>

As a result of database maintenance and normal business activities (mergers, acquisitions, divestitures) it is possible that a D-U-N-S Number assigned to a company may change. To capture these events, customers should monitor the //Organization/SubjectHeader/TransferDUNSNumberRegistration/TransferredToDUNSNumber XPATH available in the Detailed Company Profile data layers.

If/when a D-U-N-S Number is retired (or "deleted") from D&B's database, a change notice will be triggered with the new "retained" D-U-N-S Number (TransferredToDUNSNumber), the date of the event (TransferReasonText), and a reason that explains the type of event (TransferDate). The new D-U-N-S Number will not be registered automatically in the monitoring engine. Customers need to manually register the transferred D-U-N-S Number in order to continue to receive Change Notices.

NOTE: Change notices for D-U-N-S Numbers being retired are ONLY available by Monitoring one of these Detailed Company Profile data layers (DCP_STD, DCP_PREM, DCP_ALT_STD, DCP_ALT_ENH and DCP_ALT_PREM).

<ChangeEvent>

<PCMElementXPATHText>//Organization/SubjectHeader/TransferDUNSNumberRegistration</PCMElementXPATHText>

<Element ChangeType="NewlyAdded" PCMElementXPATHText="//Organization/SubjectHeader/TransferDUNSNumberRegistration/TransferReasonText">Duplicate Record Transferred</Element>

<Element ChangeType="NewlyAdded" PCMElementXPATHText="//Organization/SubjectHeader/TransferDUNSNumberRegistration/TransferReasonText@DNBCodeValue">420</Element>

<Element ChangeType="NewlyAdded" PCMElementXPATHText="//Organization/SubjectHeader/TransferDUNSNumberRegistration/TransferDate">2014-01-01</Element>

<Element ChangeType="NewlyAdded" PCMElementXPATHText="//Organization/SubjectHeader/TransferDUNSNumberRegistration/TransferredToDUNSNumber">123456789</Element>

</ChangeEvent>

NOTE: In the case of a "Straight Deletion" event, the TransferredToDUNSNumber field will not be present in the Change Notice.

If the AutoRenewalIndicator was set to true when the initial AddMonitoringRegistration request was made, it is recommended that the developer issue a UpdateMonitoringRegistration request for the subject D-U-N-S Number and set the MonitoringRegistrationStatusText field to "Cancelled" when notified of a retirement event.

The linkage (or family tree) monitoring feature triggers notifications when a member is added to, moves within or departs from a corporate structure. Here are some examples:

NOTE: The Change Trigger Feed from Linkage will have the deleted/departed members first followed by the new/moves within members.

Example #1: Company "F" is added to the "A" tree, directly "owned" by company "E"

A
|
B - C
|    |
D    E
     +
     F

In the change notice, the following items should be examined:

• SubjectHeader will equal D-U-N-S Number of "A",
• LinkageChange.DunsNumber will equal D-U-N-S Number of "F",
• LinkageChange.ChangeType will be Add,
• LinkageChange.GlobalUltimateOrganization.DunsNumber will equal D-U-N-S Number of "A"
• LinkageChange.UpwardFamilyMemberOrganization.DunsNumber will equal D-U-N-S Number of "E".

Example #2: Company "F" is moves within the "A" tree, directly "owned" by company "C"

In the change notice, the following items should be examined:

• SubjectHeader will equal D-U-N-S Number of "A",
• Change Event 1
  • LinkageChange.DunsNumber will equal D-U-N-S Number of "F",
  • LinkageChange.ChangeType will be Drop,
  • LinkageChange.FormerUpwardFamilyMemberOrganization.DunsNumber will equal D-U-N-S Number of "E".
• Change Event 2
• LinkageChange.DunsNumber will equal D-U-N-S Number of "F",
• LinkageChange.ChangeType will be Add,
• LinkageChange.UpwardFamilyMemberOrganization.DunsNumber will equal D-U-N-S Number of "C".

Example #3: Company "F" leaves the "A" tree, now directly "owned" by company "H"

In the change notice, the following items should be examined:

• SubjectHeader will equal D-U-N-S Number of "A",
• LinkageChange.DunsNumber will equal D-U-N-S Number of "F",
• LinkageChange.ChangeType will be Drop,
• LinkageChange.FormerGlobalUltimateOrganization.DunsNumber will equal D-U-N-S Number of "A"
• LinkageChange.FormerUpwardFamilyMemberOrganization.DunsNumber will equal D-U-N-S Number of "C".

If the "G" tree is also being monitored, a second change notice will be triggered:

• SubjectHeader will equal D-U-N-S Number of "G",
• LinkageChange.DunsNumber will equal D-U-N-S Number of "F",
• LinkageChange.ChangeType will be Add,
• LinkageChange.GlobalUltimateOrganization.DunsNumber will equal D-U-N-S Number of "G"
• LinkageChange.UpwardFamilyMemberOrganization.DunsNumber will equal D-U-N-S Number of "H".