Releases: checkmarble/marble
v0.39.0 - Performance and quality of life
This week, the Marble team spent a lot of time to make the tool respond faster, especially on the rule builder side.
Meanwhile, background work is continuing on our revamped case manager !
New features
- Cases can now be snoozed: set yourself a reminder to review the customer in a case again in the future
- The new public API v1 to interact with sanction checks by API (without Marble case manager) is live in beta version - still susceptible to evolve in the short term. checkmarble/marble-backend#891
Bug fixes
- test run decisions were not created on the
POST /decisions/allendpoint checkmarble/marble-backend#906 - The backend now works with a custom database name (other than "marble" and with a custom database user name (other than "postgres") They must however be used consistently. checkmarble/marble-backend#905
- CSV ingestion would break if the file contrains duplicate entries by object_id checkmarble/marble-backend#912
- Fix a memory leak in the backend worker checkmarble/marble-backend#927
Various improvements
- We spent a lot of time to make the rule builder interface faster to respond, we hope you'll notice it ! checkmarble/marble-frontend#735
- Switch to go 1.24 for the API
- List entries can now be added by the builder role level
- Handle timezone-less RFC3339 datetimes (such as
2025-03-25T00:00:00) - Custom lists are now sorted alphabetically
- clear, readable error messages when ingesting CSV, covering a lot more errors
- confirmation is no longer asked when changing a status in the case manager
- cases can now be opened in different browser tabs
0.38.4 - Hotfix: sanctions dataset format
Hot fix released to correct an ongoing bug, causing app versions 0.38.0 to 0.38.3 (backend or frontend version >= v0.38) to display an error message on app startup.
This is caused by unexpected "null" version numbers read on Opensanctions datasets.
0.38.3 - Sanction details in review interface and bugfix
This week's release is a minor one, with more background work in preparation.
Feature
- include details of which sanctions are on an entity, in the sanction match review interface
Bugs
- corrects a bug that prevented a test run to start in some cases (depending on any new types of aggregates being used in the new tested version compared to the live version)
0.38.2 - Bug fix
Fixes a bug on the POST /decisions/all endpoint, that returned a 500 error if any of the decisions did not pass the trigger condition.
0.38.1 - Bug fix
Fix a critical bug introduced in the previous release, where many useless indexes would be created on ingested cliente data, eventually making ingestion grind to a halt.
Also fixes two format errors in the docker-compose-dev.yaml file, which made it difficult to use.
0.38.0 - Major doc update, bugfixes and UI improvements
Warning
This release has been patched in 0.38.2. Use that version instead of the present one.
Content
This week's release is the occasion for us to propose a long overdue rewritten deployment documentation.
You will find it in the https://github.com/checkmarble/marble/tree/main/installation folder.
With this, we tried to give a more step-by-step guide on configuring Marble, making the configuration files more readable, removing ambiguity of the format expected by some configuration elements, and generally make it much easier to self-host Marble.
We released some other feature improvements and bug fixes:
Improvements
- sanction check matches display links to the wikidata page of entities
- sanction check match details correctly break lines for non latin text
- sanction check configuration trigger condition is now options, like the scenario level trigger condition
- test run statistics are computed in the background automatically, for a much faster display in the app
Bug fixes
- test run statistics by decision outcome were wrong in some cases
- test runs are now correctly limited to one active per scenario, not one per organization
- batch (scheduled) execution of scenarios was not working for scenarios with an empty trigger condition (last week's release)
Deployment instructions
Warning
Change in the required environment variables to run the Marble application
Some environment variables expected by the backend and frontend containers for the Marble app have changed. The detail is below:
- Frontend environment
MARBLE_API_DOMAIN_CLIENTrenamed toMARBLE_API_URL_CLIENT(format unchanged)MARBLE_API_DOMAIN_SERVERrenamed toMARBLE_API_URL_SERVER(format unchanged)MARBLE_APP_DOMAINrenamed toMARBLE_APP_URL(format unchanged)
- Backend environment
MARBLE_APP_HOSTrenamed toMARBLE_APP_URL. Format was a host name (host + port, e.g.localhost:3000), is replaced by a proper url (e.g.http://localhost:3000) to take the same format at the environment variable with the same name on the frontend- the scheme (http/https) used for CORS was based on the value of the
ENVenvironment variable (httpifdevelopment,httpsotherwise), now directly uses the value ofMARBLE_APP_URL=> no impact expecter for customers in a production environment
Make sure to modify the values passed to your binary or container (or start by adding the new ones if you are not running with docker compose) before you upgrade to version 0.38.
We apologize for the added complexity of this release, but this evolution should make Marble easier to configure in the long run by reducing ambiguity.
0.37.0 - Redesign & usability improvements
This week’s release is focused on bug fixes and small feature improvements for your quality of life.
Bug fixes
- Fix a bug impacting webhooks sending
- Fix an issue where the test run page was failing to load on organizations with large numbers of decisions
- Fix a but where the test run end date was one day earlier than what it appeared to be
Improvements
- Sanction checks are now displayed in the logical order (highest score at the top)
- The trigger condition is now optional for scenario. No more need to set « true = true » for scenarios that should run on all payloads!
- The version of the backend and frontend are now displayed in the home page help center. Convenient for debugging !
- Features that are not available due to a missing dependency are now greyed out rather than displaying misleading error messages (sanction checks, analytics, webhooks)
- The scenario rule edit page has been redesigned
Redesign

0.36.0 : Sanction screening, PATCH, better agregate creation and performance improvements
Sanction screening
We've partnered with our friends at Opensanctions to add to Marble
- Real time sanction checks, fully self hosted with unlimited checks, or connecting to Opensanction pay as you go API
- Over 240 lists, available and selectable, updated several times / day, with a warning when the last refresh is older than 24h
- Configurable sensibility threshold in the settings, driving a state of the art matching algorithm using both fuzzy matching and phonetic matching
- Capacity to force the outcome of the scenario in case there's a sanction hit
- Complete case management review interface, with the detail of each hit
- Whitelisting of counterparts : you can define a unique identifier (account number, phone number...) and decide to whitelist the discarded hits to avoid repeat alerts
- Refine of the search : an operator can add additional data (after asking the customer for documents for eg) and restart the search for more precise results
The decision API will be updated in the next release.
See also our documentation for how to deploy a sanction check scenario, and review hits, in our public documentation.
Sanction screening is a separate module sold with a specific licence, reach out to us if you'd like to know more. As part of our commitment, NGO and non profit organisations can obtain a licence key for free.
Cleaner interface for agregate building
The interface for creating agregate has been completely refurbished, clarifying the object selected, and the fields used as filters.
Patch API
A new method is available for the ingestion API : Patch
You can now update a part of the object when using this method instead or resenting the complete payload.
When creating an object, all fields set as required are still mandatory.
Performance increase
We've added agregate persistence during a scenario run. Each agregate is now calculated only once during each decision, removing DB load and accelerating scenarios using several times the same agregates in their rules
Fix
- Open API specs are now correct when downloaded from the front end
- Random crash when accessing a test run
New agregate creation

v0.35.0 : data viewer and fixes
This release contains a new feature that was at the top requests of our users : the data viewer
- Check if an object has been ingested by typing its ID in the viewer. You'll get the detail of the object as well as the latest ingestion date
- Navigate your data within the case manager : each link within your decision object gives you a view of the underlying data. You can now easily check the customer profile from a transaction for eg.
The release also include multiple bugfix, including :
- Fixed an error generated when checking the result page of a test run
- Removed a cookie linked problem that was preventing the API key generation in the setting menu
- other minor display fixes
Breadcrumbs, bugfixes and performance optimizations
Content
This week's release focuses mostly on bug fixes and some quality of life improvements, while we work on the next big feature in the background.
- Breadcrumbs for navigation: as the app is getting more complex, navigation was becoming more painful. This should help users navigate different parts of the app, and the pattern will be used everywhere.
- Performance optimizations for the rule evaluation: branches of a rule that have no impact on the final output of a rule (for example because another branch of the "AND" condition is known to return "false") will no longer be executed. This will allow us to bypass some aggregates calculation, for a better overall performance of the decision creation API.
Bug fixes
- the pagination function for cases was no longer working
- the LICENCE_KEY environment variable was required for starting the frontend container, even though it was no longer used by it
- user creation was broken since the last release for open-source users of Marble
- user role changes were more restricted than they should be
Breadcrumbs for navigation



