Firm Configuration Report ZIP delivery with expanded insights

We’ve enhanced the Firm Configuration Report (FCR) so that you can more easily understand your current screening setup and how it has changed over time. 

When an FCR is requested via API, it will now be delivered as a ZIP package containing three files:

1. Firm Configuration Report (PDF): A snapshot of the firm’s current screening configuration.
2. List of Lists (Excel): New with this release, this file provides a clear, filter‑aware view of which monitored lists a firm is screening against. Each FCR request regenerates this file to reflect the most current eligible lists. This file:
   • Shows included and excluded lists.
   • Accounts for the firm’s filter and, if applicable, CVIP profile.
   • Uses a dynamic list source so that new lists added to Grid appear automatically. Intentionally suppressed lists, for example, a test list used for validation, do not impact results.
3. Consolidated Filter & CVIP Audit Log (PDF): New with this release, this file provides a centralized history of filter and CVIP configuration evolution over time, showing when key screening rules were added, updated, or removed.
   • Includes up to 3 years of history.
   • Limited to 10,000 records per category, for example, FILTER_PROFILE or CVIP. If more than 10,000 changes exist in a category, only the most recent 10,000 records will be available
   • Covers filter and CVIP changes only. Other firm‑level changes are not included in this release.

For CVIP changes made before the March 3rd release, the audit entries do not include details of which risk event codes, stage codes, or entity types were modified.

For CVIP changes made after the March 3rd release: 

• Audit log will display a record indicating CVIP profile details along with the change request number, which is required, after every change.
• Some users may see Expression: STAGE[-1] in a CVIP Audit log rule record. This indicates the rule code has not been applied to any stages, as shown by the detail Stages: None in the record. This scenario is invalid but noted here for reference.

We have also enhanced the format of the Last Updated timestamp in the FCR to MM/DD/YYYY HH:MM UTC to improve consistency. This provides a precise and reliable reference that can be used for audits, internal control reviews, and regulatory documentation.

These changes reduce the need for ad‑hoc explanations of a firm’s screening configuration and recent history by providing a self‑service view directly within the FCR ZIP package. To learn more about this ZIP package, reach out to your Moody's representative.

Audit Log Search for self‑service filter and CVIP history

We have introduced a new Audit Log Search screen in Review to give you clearer visibility into how your screening configuration has changed over time.

The Audit Log Search screen allows you to:

• Review configuration history for filters and CVIP in one place.
• Search and filter audit records to identify what changed and when.
• Export the returned audit log records so they can be used for internal review or regulatory and audit documentation.

The PDF generated from the Audit Log Search screen includes only the events associated with the selected category, for example, just filter-related or just CVIP-related changes.

Key benefits

You can now review how your filter and CVIP configurations have evolved over time, prepare materials for governance or regulatory reviews, and answer common questions about firm configuration changes without contacting support.

This enhancement provides:

• Self‑service access to filter and CVIP configuration history in one place
• Faster answers to configuration change questions without manual investigation
• Standardized, exportable audit logs for client discussions, audits, and regulatory reviews
• Reduced reliance on support for routine configuration history requests

Notes

Audit Log Search provides configuration history within the following scopes.

• Searchable and exportable audit data is limited to a three-year date range.
• Records are limited to 10,000 per category, for example,  FILTER_PROFILE or CVIP. If there are more than 10,000 changes in a category, only the most recent 10,000 records will be available in the exports.
• Audit history focuses on filter and CVIP changes. Other firm‑level configuration changes are out of scope for this release.

For CVIP changes made before the March 3rd release, the audit entries do not include details of which risk event codes, stage codes, or entity types were modified.

For CVIP changes made after the March 3rd release: 

• Audit log will display a record indicating CVIP profile details along with the change request number, which is required, after every change.
• Some users may see Expression: STAGE[-1] in a CVIP Audit log rule record. This indicates the rule code has not been applied to any stages, as shown by the detail Stages: None in the record. This scenario is invalid but noted here for reference.

If you require a more exhaustive history than what is available in the UI and PDFs, contact your Moody’s representative.

Access

To access the Audit Log Search screen, you must have an audit-specific role enabled. If you can not currently access the Audit Log Search screen, please contact your Moody’s representative to request that the appropriate role be granted.

OAuth2 scope support for GRID webhooks

This release adds support for an optional OAuth2 scope parameter in Grid API webhook token requests. The scope value can be configured for your integration by a Moody’s team member. When enabled, it is included in the OAuth2 token request body while preserving existing behavior for all current integrations.

Inquiry History API performance and data quality improvements

We’ve enhanced the grid-service/v2/inquiry/history endpoint to provide:

• Faster responses: The query has been optimized, significantly reducing response times for Tracking IDs with very large volumes of related records.
• No duplicate entries: We’ve corrected issues that could cause duplicate entries to appear in the history response in certain batch scenarios.

No changes are required to your integration. The endpoint and payloads are unchanged, and all existing calls will automatically benefit from these improvements.

Upcoming data enhancement for Nordic Politically Exposed Persons (PEP) data

As part of our ongoing commitment to data excellence, we are making a significant enhancement to our Nordic Politically Exposed Persons (PEP) collection. We will be consolidating our data to a single, superior suite of lists for all Nordic PEP designations, built on the advanced Bogard Nordic PEPs methodology.

This upgrade substantially improves screening precision by integrating key national identifiers. The dataset now includes Social Security numbers for PEPs and their Relatives and Close Associates (RCAs) in Sweden and comprehensive date of birth information for them in Denmark, Norway, and Finland.

This data enrichment, combined with the systematic removal of outdated information, ensures closer alignment with regional regulations. Consequently, your team will experience a significant reduction in false positives and receive more relevant, actionable alerts.

List changes and timeline

Effective March 31st, 2026, we will be retiring our legacy PEP lists for the Nordic region to streamline our offering and improve screening efficiency. The Nordic PEPs lists will remain as the primary, high-quality data sets for all your Nordic PEP screening needs.

The following table details the datasets that will be decommissioned and those that will persist:

Transition actions

No action is required on your part. This transition is an internal process that will be managed entirely by our data services team to ensure service continuity.

Basic Fuzzy Matching Critical Watchlist Search for Organizations in Portfolio Monitoring

Following the implementation of Basic Fuzzy Matching Critical Watchlist Search, also known as Basic Fuzzy Critical, for organization inquiry searches, this capability now extends to Portfolio Monitoring.

With this update:

• The same Basic Fuzzy Critical matching logic for organizations is applied consistently across both inquiry searches and Portfolio Monitoring
• Clients should expect more consistent behavior, scoring, and results across these workflows for critical watchlist organization screening

Existing guidance and optional enhancements, including Organization Spellchecker for non‑critical organization matching or Advanced Fuzzy Critical Search for more advanced fuzzy matching, remain unchanged.

Accuracy and consistency improvements for person searches

This release includes targeted improvements to several secondary, non-Global Name Matching (GNM), person-name search algorithms. These updates deliver enhanced matching accuracy and consistency between inquiry and Portfolio Monitoring (PM) searches, while maintaining reliable and comprehensive Critical Watchlist matching. 

Reduced false positives in Critical Watchlist searches

Expanded support for full-name compressed searches

Improved consistency between inquiry searches and Portfolio Monitoring

The Critical Watchlist search and the Unprocessable Name search have been aligned to produce more consistent results across inquiry and PM workflows, reducing discrepancies between the two use cases.

Replacement of legacy OFAC Fuzzy Matching with Basic Fuzzy Matching Critical Watchlist Search

The legacy OFAC-centric, suggestion-based Fuzzy Matching component has been removed and replaced with a more predictable and intuitive mechanism. Basic Fuzzy Matching Critical Watchlist Search, also known as Basic Fuzzy Critical, provides a straightforward, well-defined level of fuzzy matching against all critical watchlists for organizations.

The new Basic Fuzzy Matching Critical Watchlist Search has several advantages over the previous mechanism, including:

• Improved recall across all critical watchlists, including better coverage beyond OFAC-only lists
• Improved precision across organization searches
• Marked performance improvements for most organization searches
• More intuitive and consistent matching behavior
• Unified matching behavior across workflows, as this functionality will shortly be enabled for Portfolio Monitoring as well as inquiry searches, improving consistency across use cases

This release also includes updates to the GNM rescoring step to ensure more consistent behavior across inquiry searches and Portfolio Monitoring.

For non-critical Grid matching, you may experience a reduction in fuzzy matching, but should see an overall improvement in accuracy, consistency, and performance. If you are interested in a higher level of fuzzy matching for non-critical organization matching, consider enabling the Organization Spellchecker. For critical watchlist organization matching, if you require more than a basic level of fuzzy matching, consider enabling the existing Advanced Fuzzy Critical Search feature.

Name-matching system recognizes additional French titles

This release enhances our name matching system by expanding the set of French titles similar to “M. OU MME” that are recognized as honorifics in person name searches. These phrases are now treated as titles rather than as part of the name itself, improving the consistency and accuracy of matching when such titles are present. This enhancement applies only to person name searches; organization name searches are not affected. No additional actions are required to benefit from these improvements.

Expanded variant coverage for Frank

We have improved our person‑name matching to better recognize variants of the Frank / Francesco / Francis name family across languages and common nicknames. Recognition of these additional name variants will improve overall match quality and help reduce missed matches (false negatives) when different forms of the same given name are used. No action is required to benefit from these improvements.

Organization matching weight adjustments for Polish legal forms

We have made weight adjustments to reduce the scoring impact of the spółka, ograniczoną, and odpowiedzialnością Polish company type tokens. This improves the accuracy of matching for related names.

Name-matching system recognizes additional organization tokens

This release enhances organization name matching by expanding the set of recognized company-type tokens, for example, designations equivalent to LLC or Joint Stock Company, across Eastern European, Commonwealth of Independent States (CIS), Baltic, and Vietnamese names. 

As a result, organizations will match more reliably and accurately even when these tokens are added, removed, abbreviated, or transliterated in the search input. This enhancement applies to Organization name searches in Grid Search, and no action is required to benefit from these improvements. For a full list of recognized organization tokens, reach out to your Moody's representative.

Faster Entity Activation (FEA) for Portfolio Monitoring is now available 

The Faster Entity Activation (FEA) initiative delivers a major enhancement to Moody’s Analytics’ portfolio monitoring by providing clients with significantly faster visibility of new entities on critical watchlists, enabling near real-time risk detection. With FEA, critical watchlists are processed continuously and clients can now receive portfolio monitoring alerts multiple times daily, offering greater flexibility and timely risk management. 

What’s new with FEA

• Receive alerts about new entities much faster, critical watchlists are now monitored continuously, so you can detect risks and respond sooner.
• Choose how often you receive portfolio monitoring alerts: several times a day (up to six times) or just once daily, based on your preferences.
• Alerts will continue to be delivered in your preferred format (SFTP, API, or email) and will look the same as your current portfolio monitoring notifications for a consistent experience.
• If there are no new matches in a batch period, you’ll see an empty batch notification in the Review UI.

For more information, please contact your Client Service Representative.

The Swagger documentation for the v2 API has been updated to reflect the correct data types for date-related attributes accurately. Some fields were previously documented as date-time when they actually returned date values, which could lead to client confusion and submission errors. If you have built any integrations based on the previous documentation, check that you are submitting dates in the correct format for each field.

The following fields are now clearly documented as using date (YYYY-MM-DD):

• birthDt
• entityDt
• eventDt
• endDate
• fromDt
• toDt
• genericIdIssueDt
• genericIdExpDt
• issueDt

The following fields are now clearly documented as using date-time format:

• createdDt 
• completedDt
• icadOpenDt

This update ensures alignment between the API documentation and actual API responses. This helps reduce submission confusion and date-related errors, and improves developer experience and integration reliability.

Date of birth format switching

Birth date fields across the application now consistently display in the user’s selected date format. Users can update their preferred date format in Settings, and birth date fields will immediately reflect the new format. This enhancement improves clarity and consistency for all users.

Enhancements to batch and inquiry assignments 

Bulk assignment and enhanced filtering are now available in the Review UI, making it easier to manage and assign large numbers of inquiries and batches. These improvements save time and provide a more flexible, user-friendly experience. 

Bulk assignment 

Users can now select multiple inquiries or batches and assign them collectively to a user or group from the following pages:

• Batches for Review
• Assigned Reviews
• Batch Review

This streamlines the assignment process and reduces manual effort.

Enhanced filtering

The User/Group Name filter has been upgraded to a multiselect dropdown, allowing for more flexible and consistent filtering and assignment across the Review UI.

Updated legal disclaimer

The legal disclaimer in all Grid Alert and Entity PDFs, as well as the Review UI, have been updated. All new PDFs and Review UI pages now display the updated disclaimer text.

Enhanced usernames for Grid contacts

This release introduces enhanced username uniqueness rules across all Review UI environments (US, EU, IN). Usernames must now be unique in all regions and can be up to 245 characters long. This change helps to prevent security incidents and avoid data loss. 

• Extended Character Limit: The username character limit has been increased to 245 characters, ensuring compatibility with a broader range of identity providers and naming conventions.
• Improved Consistency: This update ensures consistent username handling across Grid interfaces and downstream systems. Duplicate usernames across regions will not be allowed. 
• Error messaging: 
  • If you create a duplicate username within the same region, you will receive the error message: 

    User Name is in use. Please chose another User Name. Suggested User Name: (unique username).

  • If you create a username in use in another region, you will receive the error message: 

    User Name is in use, Please chose another User Name

Users must ensure that usernames are unique and adhere to the new character limit when creating or updating user profiles. Enhanced username handling in Grid is supported for both SSO and non-SSO contact types.