Determination Anywhere 2026.05 release notes

Please review this release note in conjunction with the Determination – Enterprise Cloud (EC) 2026.04 release notes, which outline key updates to the core application. These include enhancements to the tax engine logic, regulatory compliance improvements, UI feature upgrades, and may also highlight defect resolutions and known issues – all of which directly impact the tax engine's functionality within Determination Anywhere (DA).

Thomson Reuters recognizes that security vulnerabilities in software deployed within our own environments, or within our customer environments can pose significant risk. We conduct daily vulnerability scans of ONESOURCE Determination application code and dependencies. ONESOURCE Determination Anywhere container images are scanned daily to identify and remediate security vulnerabilities. While we strive to address zero-day vulnerabilities as rapidly as possible, remediation timelines follow the Thomson Reuters Information Security & Risk Management (ISRM) guidelines based on severity classifications identified by our scanning tool, Snyk – Critical (30 days), High (60 days), Medium & Low (best-effort basis in a future release). If vulnerabilities are found after software is released, Critical issues are fixed through urgent Production releases or in the next scheduled release cycle. We aim to uphold our commitment to providing secure solutions.

Determination Anywhere (DA) 2026.05 delivers several enhancements focused on improving operational efficiency, deployment flexibility, and platform performance. Key updates include support for storing configuration and transaction audit data in customer-managed external databases, enabling stateless deployments and reducing reliance on persistent volumes. In addition, performance-related enhancements to tax engine caching help reduce startup and warm-up impacts, allowing customers to realize improved tax calculation performance more quickly and consistently across deployments. These updates address several operational challenges reported by customers while providing greater control, scalability, and transparency for DA environments.

The following topics outline the new features introduced in this release.

This release introduces support for storing DA Cloud content and configuration data in a customer-managed external PostgreSQL database. Previously, DA Cloud relied on an embedded PostgreSQL database to maintain tax content and configuration synchronized from Mothership, which created operational challenges including preventing stateless deployments, causing split-brain issues during failover scenarios, and limited customer control over database management.

With this enhancement, customers can leverage their own enterprise database infrastructure, enabling greater control over backup, disaster recovery, monitoring, security, and maintenance processes. By externalizing the content and configuration database, customers can further support stateless deployment architectures while aligning database operations with existing organizational standards and practices.

Initial support is available for PostgreSQL versions 17 and 18. Support for additional database platforms is planned for future releases based on customer demand.

This capability is optional and must be enabled through Helm chart configuration. Existing deployments that continue to use the embedded database and persistent volumes require no configuration changes. Customers should work with their ETS representative for configuration guidance and deployment assistance.

DA Cloud and DA Store now support storing transaction audit data and calculation history in a customer-managed external relational database. This enhancement enables stateless deployments by removing the dependency on DA-managed persistent volumes (PV), while providing customers with greater control over how audit data is stored and managed. The capability supports PostgreSQL, Oracle, and MariaDB databases through standard JDBC connections and can be used to meet transaction data residency requirements while continuing to support synchronization with Mothership.

By leveraging existing enterprise database infrastructure, customers can simplify operations, improve scalability, and align DA audit data management with established backup, disaster recovery, monitoring, and retention practices. Dedicated database schemas are managed through Liquibase, which can automatically create the required tables during initial startup. For organizations that require database change approval processes, standalone SQL scripts are also available for manual schema deployment.

This feature is optional and must be enabled through Helm chart configuration by setting transactionSync.jdbcMode.enabled=true. To use an external database for data residency, configure dataresidency.target=database and provide a separate database connection if different from the transaction sync database. Existing deployments that continue to use persistent volumes require no configuration changes. Customers should work with their ETS representative for configuration and deployment assistance.

This release introduces enhancements designed to improve application performance during cold start scenarios, such as pod restarts, scale-up events, or the processing of initial transactions after periods of inactivity. Previously, some DA Cloud customers experienced slower response times until the application and JVM naturally warmed up through transaction activity, particularly in environments with variable workloads, auto-scaling configurations, or frequent pod restarts.

To address this, DA now includes automated startup warmup routines that pre-initialize key application and framework components before live tax calculation requests are processed. This helps reduce first-transaction latency, improves application readiness, and delivers more consistent performance following startup and scaling events.

For DA Cloud, these cold start performance enhancements are enabled by default and activate automatically whenever a pod starts.

For DA Store, the capability is available as an optional enhancement. Customers who choose to enable it should review available CPU capacity, apply the recommended warmup and JVM configuration settings, and monitor startup performance following deployment. Customers should work with their ETS representative to determine the appropriate configuration for their environment.

This release introduces a new optional configuration that allows DA deployments to skip automatic creation and assignment of image pull secrets for DA workloads. This enhancement provides greater flexibility for customers operating in Kubernetes environments that already leverage platform-managed authentication mechanisms, such as node-level service accounts, IAM roles, managed identities, or workload identities for container registry access.

By enabling DA to rely on existing platform authentication, customers can simplify deployment configuration, reduce secret management overhead, and better align with enterprise security and governance practices. Existing deployments remain unchanged and will continue to create and use image pull secrets by default to maintain backward compatibility.

This capability is optional and disabled by default. Customers who use platform-managed registry authentication can enable the feature by setting imagePullSecret.enabled=false in the installer Helm chart values before deployment. Customers that require explicit image pull secrets do not need to make any configuration changes.

A new Security Vulnerabilities Report screen has been added to the Enterprise Cloud user interface under the Determination Anywhere menu. This self-service feature provides customers with direct access to Snyk security scan reports for each DA release, enabling greater transparency into the security posture of deployed versions.

Using this report, customers can review identified vulnerabilities, track remediation progress across releases, and compare security findings between DA versions without requiring support requests or access to Thomson Reuters internal security scanning systems. This enhancement supports customer security reviews, compliance assessments, and internal audit processes by providing timely visibility into release-level vulnerability information.

Additional information about this screen is available in the Determination Anywhere Help.

This release streamlines DA customer onboarding and operational support by enabling feature activation through APIs. Capabilities such as Prefetch, Streaming, and Bulk Import can now be enabled through standard APIs, reducing reliance on Engineering teams and enabling faster request fulfillment. Operational efficiency is improved through direct feature enablement by ETS, reducing administrative overhead, minimizing manual coordination, and accelerating the activation of DA capabilities for customers.

No customer action is required. Future releases are expected to expand these capabilities and provide broader self-service options through the user interface and integration with our standard Configuration APIs.

Documentation is now available for customers using REST-based tax calculation services that store transaction audit data through the data residency object storage capability. This documentation complements the existing Avro file documentation for SOAP/XML integrations by providing detailed field definitions and schema information for JSON-based transaction audit files.

The documentation is intended to assist customers who build their own reporting, auditing, or analytics solutions using DA transaction data stored in object storage as part of their data residency implementation. By providing greater visibility into the structure and contents of transaction audit files, customers can more easily interpret and utilize transaction data within their own reporting environments.

The JSON Avro documentation is currently available upon request from Thomson Reuters. A future enhancement is planned to make both the XML and JSON Avro documentation directly accessible through the Enterprise Cloud user interface, eliminating the need to request the documentation separately.

Additional information on data residency is available in the Determination Anywhere Help.

This release introduces enhancements to DA Store that provide greater control over cache file management during content synchronization. Customers can now configure cache file size limits to help reduce synchronization pod memory consumption and minimize the risk of out-of-memory conditions in Kubernetes environments with constrained resources.

By enabling more efficient cache management, this enhancement improves synchronization reliability, supports more consistent delivery of tax content updates, and reduces the need for reactive resource allocation changes in production environments. The default configuration remains appropriate for most deployments, while customers with stricter memory constraints have the flexibility to tailor cache file sizing to their specific operational requirements.

Customers with limited sync pod memory resources should review the updated deployment guidance and configure sync.cache.maxFileSize as needed. Following deployment, customers should monitor synchronization pod memory utilization during initial content synchronization cycles to validate that the selected configuration aligns with their environment's resource limits.

Data Residency support is now available for DA Store deployments, enabling customers to retain transaction audit data within their own infrastructure boundaries. Organizations with data sovereignty, regulatory, or compliance requirements can deploy DA Store while maintaining control over where transaction audit data is stored. This helps prevent sensitive transaction data from being synchronized outside designated geographic regions or corporate network boundaries, while preserving audit and analysis capabilities for compliance, reporting, and troubleshooting.

As with DA Cloud, transaction audit data residency is supported through Amazon S3 object storage. Data Residency is not enabled by default. Customers should work with their ETS representative to understand configuration and deployment requirements.

The following topics outline previously identified issues that have been resolved in this release.

This release includes remediation of several critical and high-severity security vulnerabilities within the DA platform, further strengthening application security and reducing exposure to known third-party component risks.

Key security updates include:

As highlighted above, vulnerability scan results are now available through a new Security Vulnerabilities Report screen within the Enterprise Cloud user interface under the Determination Anywhere menu. This report provides greater visibility into the security posture of deployed DA environments and helps support internal security and compliance review processes.

This release resolves an issue that could prevent DA from starting in environments using Apigee authentication with restricted outbound network access. Previously, the application attempted to initialize AWS Cognito-related components during startup, even when OAuth/Cognito authentication was not configured. In environments where connectivity to AWS services was blocked, this behavior could result in application startup failures when calculation history functionality was enabled.

To address this issue, DA has been updated to load authentication-specific components only for the authentication method configured in the deployment. This improvement removes unnecessary dependencies on AWS Cognito for customers using Apigee authentication and allows calculation history functionality to be enabled without requiring workaround JVM settings or external AWS connectivity.

Customers using Apigee authentication should upgrade to this version or later to benefit from this enhancement. Any previously implemented lazy initialization workaround used to bypass the issue may no longer be required and can be reviewed for removal after validating the upgrade. Customers should confirm that DA starts successfully in restricted network environments and that calculation history functions as expected. Customers using OAuth/Cognito authentication are not affected by this issue and do not require any configuration changes.

This release includes Helm chart enhancements that address two infrastructure-related issues affecting deployment reliability and data processing accuracy in DA Cloud and DA Store environments.

The first enhancement improves database consistency by updating the default Pgpool configuration to ensure read operations are directed to the primary database following write activity within the same session. This eliminates potential issues caused by replication lag between PostgreSQL primary and replica databases, reducing the risk of stale data reads and improving application reliability.

The second enhancement expands the supported Avro file naming patterns used for data residency processing. The updated logic now recognizes both Salesforce-style record identifiers (15 or 18 character alphanumeric) and UUID format (standard hyphenated format), ensuring all valid transaction files are correctly processed for reporting, auditing, and analytics purposes.

These improvements are included as the default behavior in the DA 2026.05 Helm charts. New deployments automatically benefit from the updated configurations. For existing deployments, any custom overlays previously implemented for Pgpool disable_load_balance_on_write settings or Avro file pattern support can be removed, as these configurations are now incorporated into the standard Helm chart values.