# Ripple Custody 1.42 (October 5, 2026) Version 1.42 is a short-term support (STS) SaaS release that introduces the following changes: - Omnibus support in the Portfolio Data Export Service - Duplicate endpoint prevention becomes optional - Deterministic token lookup by on-ledger identity - Signing and mobile notification security improvements - UI v2 reliability improvements ## Omnibus support in the Portfolio Data Export Service Ripple Custody version 1.42 extends the [Portfolio Data Export Service](/pt-br/products/custody/data-export/overview) to domains that use an [omnibus structure](/pt-br/products/custody/accounts-and-assets/omnibus/overview). A new [Omnibus Position Report](/pt-br/products/custody/data-export/omnibus-position-report), `POST /v1/exports/position/omnibus`, returns a domain's omnibus wallet, deposit wallets, and virtual account balances as one point-in-time report, with the columns that map each deposit wallet to its virtual account and every row to its parent omnibus wallet. Control totals are computed per account type. In the existing reports, the Position Report `accountType` column and the Movement Report `senderAccountType` and `recipientAccountType` columns can now contain two additional values, `omnibus` and `deposit wallet`. Position Reports for omnibus domains no longer include virtual account balance rows, and their control totals reflect on-chain custody holdings only. Column count, order, names, and types are unchanged, and output for domains without an omnibus structure is unchanged. Behavior change Downstream consumers that validate the account-type value set must accept `omnibus` and `deposit wallet`. Position Report totals for omnibus domains no longer include virtual account balances. For SaaS environments with an omnibus structure, omnibus support in the export service is enabled automatically with this release. In environments without omnibus it stays off: the existing reports are unchanged and the new endpoint returns `404`. On-premises deployments enable it through configuration — see [Export reference > Omnibus support](/pt-br/products/custody/data-export/reference#omnibus-support). For omnibus-enabled SaaS environments, this behavior change takes effect with the 1.42 rollout. ## Duplicate endpoint prevention becomes optional [Version 1.40](/pt-br/products/custody/support/change-history/v140#duplicate-endpoint-prevention) introduced duplicate endpoint prevention, which rejects an endpoint that matches the address, ledger, and destination tag or memo of an existing endpoint in the domain. Some integrations register several endpoints for one address by design, for example one endpoint per client that allowlists the same address. To support both models, version 1.42 makes duplicate prevention optional and restores the pre-1.40 default. A new optional `allowDuplicate` field on the `v0_CreateEndpoint` and `v0_UpdateEndpoint` payloads controls the behavior. When you omit the field or set it to `true`, Ripple Custody accepts the duplicate. When it's `false`, Ripple Custody rejects the intent as versions 1.40 and 1.41 did. In the UI, the endpoint creation and update forms gain a **Prevent duplicate endpoints** toggle that is on by default, so UI users keep the protection unless they turn it off. No other endpoint validation changes. Deprecation Ripple introduces `allowDuplicate` as a deprecated field and plans to remove it on October 1, 2027, after which Ripple Custody always rejects duplicate endpoints. If your integration relies on duplicate endpoints, you have until then to migrate. If you want rejection now, send `allowDuplicate: false` rather than relying on the default. When you allow duplicates, an incoming deposit on a shared address resolves to every matching endpoint, most recent first. The list appears in the transfer's `addressDetails.resolvedEndpoints` field and in the policy evaluation context for releasing quarantined transfers. This is the pre-1.40 behavior. For the field reference and UI procedure, see [Manage endpoints](/pt-br/products/custody/accounts-and-assets/endpoints/manage-endpoints#duplicate-endpoint-prevention). ## Deterministic token lookup by on-ledger identity Ripple Custody version 1.42 adds three query parameters to the [List tickers](/pt-br/products/custody/reference/api/openapi/tickers/gettickers) operation, `GET /v1/tickers`: `issuer`, `assetCode`, and `assetReference`. They filter tokens by the identifiers the ledger assigns to them, so a client that knows a token's on-ledger identity retrieves exactly one ticker in a single call. The existing `name` and `symbol` filters are user-editable and not guaranteed to be unique, so they can't be used to resolve a token to exactly one ticker. The new parameters filter on ledger-assigned identifiers instead. The parameters work across ledgers. Use `assetCode` and `issuer` together for tokens that a ledger identifies by a code and an issuing address, such as XRPL trust line tokens and Stellar assets. Use `assetReference` for tokens that a ledger identifies by a single reference, such as an XRPL Multi-Purpose Token issuance ID, an EVM contract address, a Solana mint, or a Hedera token ID. Each parameter accepts repeated values. Combine the filters with `ledgerId` to keep the result unambiguous across ledgers. Existing filters are unchanged. Exact match The identity filters match the stored value exactly, with no normalization. Send XRPL currency codes in the form the ticker stores them: ASCII for three-character codes and uppercase hexadecimal for longer codes. The API ignores unknown query parameter names, so confirm that `count` is `1` before you use the result. For the parameters to use on each ledger and worked examples, see [Find a token by its on-ledger identity](/pt-br/products/custody/accounts-and-assets/tokenization/token-management/api/find-token-by-ledger-identity). ## Signing and mobile notification security improvements Ripple Custody version 1.42 and **Ripple Custody: Auth & Sign** app version 5.12.0 strengthen security when you sign an operation or approve a login: - Ripple Custody generates the two-digit verification code for each signing request, and the code can't be derived from the request. - A signing request reaches only the phone of the user who created it, and every signature from a phone is verified against the user's registered keys. - Push notification registration is tied to your signing key, so only your device can register or unregister itself for your user. The first time you open app version 5.12.0, it re-registers your device with one biometric prompt. - Ripple Custody rate limits login requests per user. Update the app before compatibility mode is turned off Version 1.42 ships with a compatibility mode turned on, so apps older than 5.12.0 keep working. Ripple turns compatibility mode off per environment once most active devices run version 5.12.0 or later. From that point, older apps can't sign. For the updated procedures, see [Register and log in with the UI](/pt-br/products/custody/identity-and-access/authentication/ui-authentication). For on-premises deployments, see [Notifications configuration](/pt-br/products/custody/deployment/reference/notifications#verification-code-compatibility-mode) for the compatibility mode setting and [OAuth server configuration](/pt-br/products/custody/deployment/reference/oauth-server#environment-variables) for the login rate-limit variables. ## UI v2 reliability improvements UI v2 has been further improved with bug fixes, component hardening, better observability and end-to-end testing, making it more reliable. ## Distribution and deployment Ripple progressively deploys Version 1.42 across SaaS environments starting on the release date. ## Activation and support Ripple takes great care in testing its applications and ensuring that there are no regressions or breaking changes. Should you experience unexpected behavior, reach out to the Support team by creating a ticket on our [Support Portal](https://metaco.atlassian.net/servicedesk/customer/portal/1) or contact your Customer Partner Engineer (CPE).