Financial service institutions are subject to a high number of complex, frequently changing regulations that vary greatly from jurisdiction to jurisdiction. Institutions might have to prove to regulatory auditors how specific decisions were made. A large volume of data that drives those decisions is captured from a variety of sources such as internal databases, customer self-service, manual entry by employees, and third-party systems. Institutions must be able to track where the data was initially captured from and how it changes over time.

The Data traceability feature enables you to identify and track data objects and to configure auditable entries on those particular data objects. Afterward, the data change tracking engine scans for changes and saves them in an easily accessible data change repository.

For more details about how to extend data traceability properties, see the Implementation Guide on the Pega Client Lifecycle Management for Financial Services page.

Customer Lifecycle Management data change tracing functionality extends the Pega Platform data change auditing infrastructure by:

• Coexisting with default case history track-level tracking.
• Tracking changes on the customer data model on master profile instances (PegaFS-Data-Party-MasterProfile) as well any other persisted (saved in the database) data objects (in addition to work cases).
• Storing change history in a dedicated table where the information is properly exposed for further usage and reporting.
• Tracking data elements at every nested level, regardless of the level of depth in the data model (ability to easily configure and trace pages into pages when required).
• Tracking the following data along with the change.
  • Source information
    • Source Application – application on which the change is performed, for instance, Customer Lifecycle Management for Investment Banking or Know Your Customer for Financial Services. This value is configurable and dynamic.
    • Source Context – context on which the change is performed, for instance, manual collection, Markit KYC.com provider data, Clarient provider data, and so on. This value is dynamically retrieved based on some internal introspection pages.
    • Source Operator – the operator who performed the change. This is left empty if the change is automatic.
    • Source Thread Node – the node on which the change is performed. The information is retrieved from the thread system page.
    • Source Thread IP – the IP address from which the change occurred. The information is retrieved from the thread system page.
  • Target information
    • Customer ID – customer identifier for the tracked change.
    • Case ID – work case identifier for the tracked change.
    • Target Context – data vehicle tracked, for instance, customer master profile.
    • Target Element – data element changed, for instance, city.
    • Target Element Path – path to the data element changed within target context, for instance, Address(Home).
  • Values
    • Previous Value – target element value previous to the change, for instance, Cambridge.
    • Final Value – target element value after the change, for instance, Somerville.
  • Comment
    • Change Comment
  • Custom properties
    • Two custom properties available for extension/specialization
  • Change timestamp
    • Timestamp

• Enabling you to extend and customize for more specialized needs by means of two custom properties exposed in the mapped table.

Data change history report definition

Foundation for Financial Services provides a reusable, common report definition for showing data change history. This report definition allows filtering by:

• Case ID
• Customer ID
• Source context
• Target context
• Target element ID
• Target element path

This is available as a reusable and extendable asset for financial institutions to configure as needed.

For more information about how data traceability is implemented, see Data traceability - implementation details.