What's New at spektr

Features

Moody's monitoring for company changes

You can now use Moody's as a monitoring vendor to track changes to company names and company status. Monitoring runs automatically once a week, in step with Moody's own data updates, and every detected change creates an alert that works like DnB monitoring: review what changed and accept or reject it. spektr records when each company was last checked, so an alert only covers new changes.

What this changes for you: Nothing changes until your workspace starts monitoring with Moody's.

Indicators you can change right from the profile

You can now change an indicator's state directly from its status pill on the customer profile. The pill opens the four states with plain labels: "No match", "Match confirmed", "For review" and "Not screened" for screening indicators, and "Verified", "Not verified", "For review" and "Not screened" for verification. If the current state came from a process, the change asks "Override the process result?" first. A manual change shows who set it and when, and Revert restores the process result; the next process run replaces a manual state.

What this changes for you: The pill replaces the previous edit modal, and indicators no longer show raw states like cleared or notCleared. Analysts can correct and undo an indicator inline, so it is worth updating your work instructions.

Discrepancy alerts with explicit outcomes

Discrepancy alerts are now clearly distinct from monitoring change alerts. Analysts decide each discrepancy on its own, or every pending discrepancy in a table at once, using "Accept discrepancies" and "Reject discrepancies". A resolved alert shows the outcome: accepted, rejected or partly accepted, and the same outcome lands on the customer timeline. Downstream, the alert node outputs a new discrepancy_alert_outcome field, so routers and scenarios can branch on the decision. Accepting a field discrepancy applies the vendor's value to the record; rejecting keeps the stored value.

What this changes for you: A saved router or scenario with a condition on monitoring_alert_scenarios_status after a discrepancy alert no longer matches, because discrepancy alerts now emit the new field instead. Review those conditions.

Improvements

Restore a field to its last system value

When a field was last written by a user, the field-history popover now offers Restore on the newest system-written value. The restored value is staged and saved together with your other edits. Field history now also records changes made by vendors, the API and processes, not only by users.

What this changes for you: Correcting a manual entry no longer means retyping the old value. No other workflow change.

Alerts can auto-resolve when the last hit is decided

A new alert resolution setting (off by default) resolves an alert automatically once its last hit is decided, by an analyst or by spektrAI. Resolving the last hit shows a warning that lets you keep the alert open. Available in English and German.

What this changes for you: No change unless you switch the setting on in the alert settings dialog.

Case transactions table opens at 50 rows

The linked transactions table on a case now opens at 50 rows per page, and the page-size selector offers 10, 20, 50 and 100. Other tables keep their current settings.

Reorder entities in associated entities forms

You can now reorder entities in associated entities forms by drag and drop. Previously only individual fields could be moved.

More spektr fields in duplicate detection

The related-entities deduplication picker in the Customer Duplicate Detection node now also accepts spektr fields, such as country.

Transaction monitoring no longer emits process run events

Transaction monitoring executions no longer generate process_run_start or process_run_end events; other process types are unchanged. The webhook and event documentation has been updated to match.

What this changes for you: If your integration listens for process run events from transaction monitoring, it stops receiving them. Nothing else changes.

spektrAI case solver can use transaction data

Case-solving AI subtasks that involve transactions no longer fail for missing data: the case task solver can now see transaction data.

German localisation, continued

Another round of German polish: adjusted terms and unified wording, previously hardcoded English texts are now translated, dates and numbers use German formats, the form editor's card layout is updated, and the Related entity changes view is fully translated.