User permission changes now take effect immediately

Previously, changes to account permissions did not interrupt a current Grid session; the system continued running under the old permissions until the session expired. Now, changes to your permissions will end your active session right away, and you'll be asked to log in again. New permissions take effect with the next login after a voluntary or involuntary logout. This applies to all clients, including those who log in via SSO.

Updated country name: Republic of North Macedonia

We have updated the country name shown throughout the platform from The Former Yugoslav Republic of Macedonia to its current official name, Republic of North Macedonia.

This change means that any entity, account, or search result associated with this country will now display the updated, internationally recognized name. You do not need to take any action. The update will appear automatically and will not affect any of your existing data or configurations.

Moody's is notifying clients that Batch ID values will soon exceed the range of a 32-bit integer.

What's changing

Batch ID values will grow beyond the range that fits in a standard 32-bit integer (values above 2,147,483,647). This affects every delivery channel where Batch ID is provided, including the API (SOAP and REST), SFTP response files (both XML and pipe-delimited formats), and reports. 

Based on current volumes, Batch ID values are expected to exceed the 32-bit limit in December 2026. Moody's expects to have all supporting changes deployed by end of August 2026; this deployment does not change the format or values you receive today. Values will grow naturally as volumes increase.

Who this affects

Any integration that stores or parses the Batch ID field using a 32-bit integer type (for example, int in Java/C#, or a database column defined as INT/INTEGER). This includes Batch ID appearing in API responses, SFTP response file headers, and SFTP pipe-delimited alert records (where Batch ID is part of nearly every row, not just the header). Once Batch ID values exceed the 32-bit limit, these integrations may encounter errors, truncated values, or data corruption.

What to do

Prior to October 31, 2026:

• Review how your integration stores and parses the Batch ID field across all channels you use (API, SFTP response files, reports).
• Confirm that storage (database columns, variables, message formats) uses a 64-bit integer type (e.g., BIGINT, long, Long, Int64) rather than a 32-bit type.
• If you consume SFTP pipe-delimited response files, confirm your parsing of the compound alert-record key (Batch ID plus Inquiry ID) also supports the larger value.
• If you generate code from Moody's Swagger definitions or from a service's live WSDL endpoint, confirm the generated types and your downstream storage use 64-bit integer or string types, or you can regenerate after Moody's deployment completes. 
• Test your parsing and storage with a synthetic Batch ID value greater than 2,147,483,647 (e.g., 3,000,000,000).

Timeline

• Act now. This change is safe to make immediately and does not depend on any Moody's deployment. Updating early removes the risk entirely.
• Complete and confirm your updates no later than October 31, 2026. Treat this as a backstop, not a target. It exists to leave buffer before the projected crossover, and waiting until Q4 risks colliding with your own year-end change-freeze windows.
• Based on current volumes, Batch ID values are projected to exceed the 32-bit limit in December 2026. This projection can move earlier if volumes grow; it is not a guaranteed date.
• No action is required if your integration already uses 64-bit types.

Questions? Contact your Moody's account representative or support team.

Improved watchlist matching for Unknown inquiries

We improved watchlist matching for inquiries submitted with the inquiry type Unknown. Unknown inquiries that are classified as an organization are now also checked for an exact person name match against watchlists. This improvement applies to initial screening, with Portfolio Monitoring support to follow.

Improved visibility into batch and inquiry processing status

We are enhancing how batch and inquiry statuses are reported so that you have a clearer, more accurate view of your processing results. If batch processing fails, the batch will be marked with a new Failed status that is be reflected wherever batch and inquiry statuses are shown. A Failed status shows as soon as processing fails due to an error or timeout, providing a more precise picture of batch and inquiry states than the Processing status. If a failed batch had replaced an earlier submission under the same tracking ID, the earlier submission is automatically restored so your records reflect the last valid state.  

This change gives you more immediate insight into your batch processing without needing to reach out to support. No action is required on your end to take advantage of this improvement. The new Failed status is available alongside the batch and inquiry status values you already use today.

Expanded name length support for subject iList uploads

This release increases the character limits for person and organization names in iList uploads.

• The character limit for person names and person alias names is now 128 characters
• The character limit for organization names and organization alias names is now 350 characters. 

This update enables you to submit longer legal names that may exceed the previous limits. If a submitted name exceeds the new limit, the system continues to provide an error message listing the specific entry that exceeded the limit, making it easy to review and correct. No action is required on your part to take advantage of these expanded limits, as they will be applied automatically.

Erased inquiries are now read-only during batch review

We've improved how deleted inquiries are handled during batch review. Previously, a deleted inquiry could still show clickable Review, Reassign, or Stop options in the Alert Decisioning screens. With this release, deleted inquiries are now shown as DELETED and are read-only, so that match decisions cannot be changed. In addition, batches now automatically complete and cannot be reopened when all of their inquiries have been deleted. 

Deleted inquiries remain visible and are still included in counts and reports, so your records stay complete and accurate. Non-deleted inquiries are unaffected by this change.

Enhanced event coverage per entity profile

As part of our ongoing effort to refine our baseline filtering methodology, we have expanded the depth of event coverage available per entity profile across Grid output channels. This means that you now have access to a more comprehensive view of screening events when reviewing entity risk profiles in the screening UI, case reports, PDF exports, response files, and API responses.

Previously, event visibility could vary across channels due to system-specific event limits. This update removes those differences and may expand the volume of events shown within your existing matching and ranking logic. It improves the consistency and depth of what you see, without changing how events are selected or prioritized.

The actual number of events displayed depends on the volume of relevant events available for your firm's configuration. For entities with additional events beyond previous count limits, this update makes those events visible to you. This enhancement is reflected across Grid output channels, so the experience is aligned regardless of how you access your data.

No action is required. This update is applied automatically, and there are no changes to your workflows, integrations, or firm configuration.

Increased Grid v1 and v2 API address character limits

The Grid API now accepts up to 255 characters for address fields, including city, country, address line, and region/state/province. 

Improved Grid v1 and v2 API Swagger code sample accuracy

The Grid Swagger documentation for both API v1 and API v2 has been updated to more accurately reflect response payloads from Grid endpoints. Field names and response samples have been updated to give you a clear, reliable reference when building and maintaining your integrations. 

With more complete and accurate field definitions, you can streamline code generation and spend less time cross-referencing live API responses. This improvement also supports smoother onboarding for new integration work.

Monthly Portfolio Report: multiple address support

Effective with the July 10th report, the Monthly Portfolio Report delivered to your SFTP dropzone now includes all addresses on file for an inquiry, including inquiries that have more than one address. Previously, address data was not included for inquiries with multiple addresses.

What is changing

The report now supports up to three addresses per inquiry. The original first-address columns remain unchanged, and new columns have been added for the second and third addresses:

• First address: address, city, state_province, country, postal_code
• Second address: address2, city2, state_province2, country2, postal_code2
• Third address: address3, city3, state_province3, country3, postal_code3

When an inquiry has fewer than three addresses, the unused columns are left blank so that every report follows the same consistent structure.

What you need to do

If you process the report automatically, please confirm that your import or parsing handles the additional address columns. The original first-address column names have been preserved to minimize impact on existing processes. No action is needed to begin receiving the additional address data. It will appear automatically starting with the July 10th report.

The Grid web interface will be getting a refreshed look on August 20. Here's what's changing and what stays exactly the same.

What's new

• A more modern look and feel across the application.
• An improved sign-in and account recovery experience.

This is mostly a visual update, not a change to how you work.

What stays the same

• The URL stays the same, so you can reach the new application just as you do today once it goes live.
• You'll sign in with the same credentials you use today.
• Your workflows, features, and saved work are unchanged.
• None of your data is affected.

Preview

A preview of the new Grid web interface. This view may change slightly before launch.

A preview of the new Batches For Review page. This view may change slightly before launch.

Want a video preview of the new UI? Open the Resource Center in the web interface and look under the Resources tab.

Questions

If you have any questions or concerns, contact clientservices@moodys.com.

Improved Search on Inquiry Full History page

We've made improvements to the Inquiry Full History search page in Review to help you get faster, more reliable results. Going forward, searches will require a  Name, Tracking ID, Reporting ID, or the newly added Inquiry ID, in addition to a date range. This change prevents searches from timing out due to overly broad queries. If you search without an identifier, you'll see a prompt guiding you to add one. The new Inquiry ID field allows you to look up a specific inquiry by its exact ID. Other existing search options and wildcard behavior remain the same.

Name-matching system recognizes additional organization language tokens

This release enhances organization name matching by expanding the set of recognized entity-type phrases for the following countries: Australia, Belarus, India, Japan, Kazakhstan, Kyrgyzstan, Romania, Russia, Ukraine, United Arab Emirates, United Kingdom, United States, and Vietnam. Those phrases are treated as common organization tokens rather than as part of the core name, which improves consistency and recall when tokens appear in different forms in inquiries. 

We compared pre-implementation and post-implementation behavior on an analyst-reviewed sample of organization-name matches. In that sample, post-implementation recall ranged from about 99% to 100%. The following table shows the improvement in recall (in percentage points) for each country we have validated so far, compared with the prior configuration on the same reviewed sample.

For a full list of recognized organization tokens, reach out to your Moody's representative.

Pagination update for easier navigation

We’ve improved how you move through large sets of results in the Review UI. Instead of choosing a page from a long list, you can now type the page number and press Enter. From there, you can use the first/previous/next/last arrows to move through pages. This update helps pages load and navigate more reliably when you’re working with large result sets.

Name-matching system recognizes additional organization language tokens

This release enhances organization name matching by expanding the set of recognized entity-type phrases across Belgian, French, Latvian, Lebanese, Lithuanian, Venezuelan, Irish, and Chinese names. As a result, organizations will match more reliably and accurately even when these tokens are added, removed, or abbreviated. For a full list of recognized organization tokens, reach out to your Moody's representative.

Improved organization token stripping for Chinese and Japanese names

We improved handling of Han character organization tokens (e.g., 有限公司, 株式会社) that appear directly adjacent to other Han characters with no intervening space, as is common in Chinese and Japanese. These organization tokens will now be properly stripped when directly adjacent to other Han characters.

Name-matching system recognizes additional Dutch organization tokens

The name-matching system for organizations now recognizes a broader set of Dutch entity-type phrases as organization tokens. These additional entity-type phrases will be treated as common organization tokens rather than as part of the organization’s distinctive name. This enhancement improves precision, consistency, and recall for organization name matching when these tokens are present or absent in search inquiries.

Update Alert Decisioning Reports with Reasons for Bulk Close

Client Alert Decisioning reports now include a new Bulk Close Reason column that displays the reason entered when alerts are closed using the Bulk Close action. This makes it easier to understand and audit why alerts and batches were bulk closed in reports.

iCAD Enhancement

We’ve updated how review completion is reflected in batch metrics so that Incomplete Reviews counts display more accurately. If your process includes reassigning inquiries with completed reviews to another group or queue, the inquiry appears as not completed in the batch metrics, but the decision is still saved and retained for review.

Inquiry Full History Enhancement 

We’ve improved the reliability of Inquiry Full History searches, helping you complete high-volume searches more consistently. 

Improved critical watchlist person matching for hyphenated names

We fixed an edge case in the secondary critical watchlist person search, where hyphens retained during name analysis could prevent a secondary match that the primary search also missed. This improvement applies to inquiry and portfolio monitoring searches.

Portfolio monitoring batch discovery and retrieval enhancements in the Grid v2 REST API

We’ve introduced enhancements to the Grid v2 API to improve how you discover, retrieve, and process Portfolio Monitoring (PM) batches and non-Portfolio Monitoring batches. These updates provide clearer visibility into PM activity and consistent access to batch and alert details. 

Discover Portfolio Monitoring batches

A new batch listing endpoint in the Grid v2 API allows you to easily identify recently submitted batches and review high‑level status and counts.

Using the GET /v2/batch?submissionMethodTypes endpoint, you can now view:

• Batch ID
• Submission date
• Current batch status
• Number of inquiries
• Alert counts

You may retrieve either the most recent batches or batches within a specific date range, depending on your needs. Use responses to see batchId, alertCount, status, and submittedDate for each batch.

Retrieve full batch details

Once a batch is identified, you can retrieve the complete batch structure using the GET /v2/batch/{id} endpoint in the Grid v2 API. This endpoint now fully supports PM batches and returns a consistent JSON structure.

The response includes:

• Batch‑level metadata for status, submission type, and PM indicators.
• The full list of inquiries in the batch.
• Inquiry‑level status and review information.
• Portfolio Monitoring–specific attributes.

This behavior aligns responses for PM and existing non‑PM batches, ensuring a consistent experience across submission types. The response contains the full batch structure, including the gridInquiries array and PM metadata like portfolioMonitoring and submissionMethodType.

Retrieve alert details for PM inquiries

To retrieve inquiries that generated alerts, you can continue using the Grid v2 API alert details endpoint. Use the batch and inquiry IDs from batch details responses in the format alertId={pmBatchId}.{inquiryId} to access full alert details for each affected inquiry.

Implementation notes

For best performance, use these guidelines in the GET /v2/batch?submissionMethodTypes endpoint.

• Use case-sensitive submission method types: PM, Web, WS, System. Use NON_PM if you want Web, WS, and System in one request.
• Use either latest or from/to parameters. Do not send both in the same request.
• When using a date range, send both from and to in ISO 8601 format. Keep date ranges within 180 days.  
• If you receive a 400 message with TOO_MANY_RESULTS, narrow the date range or use latest instead.
• Include pageSize and pageNumber for pagination.

AI Review multi-threshold filtering

AI Review now supports multi‑threshold risk filtering, enabling AI Review-enabled firms to apply different thresholds to different categories of risk. This enhancement allows you to fine-tune screening behavior based on the relative importance of specific event types, rather than relying on a single, uniform threshold.

With this capability, you can classify event codes into High, Intermediate, or Low Risk groups, each with its own configurable threshold for persons and organizations. Firms can now balance filtering sensitivity with operational efficiency by using more conservative thresholds for matches associated with higher‑risk categories and filtering more aggressively on lower‑risk categories.

This enhancement provides:

• Greater alignment with firm‑specific risk appetites.
• Improved control over false positives without increasing missed risk.
• Flexible configuration without impacting existing implementations.

Unassigned event codes continue to follow the existing primary threshold, ensuring full backward compatibility and no change to current behavior unless the feature is explicitly configured. AI Review auditing and governance workflows remain unchanged.

Improved handling of date fields in the Grid v2 REST API

We’ve improved how date values (including date of birth) are returned in the Grid v2 API. Year‑only (1991), year‑and‑month (1991‑03), and full dates (1991‑03‑15) are returned in simpler, more readable formats with no appended time values. This removes the need for workarounds and eliminates confusion caused by defaults like 01-01 or 00:00:00. This behavior applies to Grid v2 API responses for firms that enable the newer notify configuration. A Moody’s team member can help you understand how this enhancement impacts your specific use cases and support you with any integration or configuration updates needed.

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.