Ripple Treasury Platform: Decommissioning and Retention Overview

  • Updated on Oct 7, 2026
  • Published on Oct 7, 2026
  • 3 minute(s) read
  • Migration Team
  • RJ
 Prev Next

Introduction to Decommissioning and Retention

The decommissioning and retention process ensures a secure, validated, and auditable exit from Ripple Treasury Platform while maintaining access to essential data for compliance and operational continuity. This article outlines the standard process for decommissioning systems and managing data retention, including backup procedures, interface shutdowns, attestation expectations, and contingency planning. It reflects current practices across both legacy and shared tenant environments.

Decommissioning Initiation

  1. The account manager submits a formal decommissioning request, typically via a ticket.

    1. A full decommissioning and destruction includes service shutdown, data deletion, and an optional backup.

    2. A point-in-time database snapshot may be requested separately only if approved under the optional 2-step process.

Data Backup and Validation

We offer data backup and validation. However, we recommend you instead gather the information you need from the Ripple Treasury Platform before decommissioning to avoid the need for a backup request and the potential additional charges.

  • Backups are not standard and may are only provided upon request.

  • There may be a charge for backups due to the time and effort involved.

  • A full database backup (if requested) is taken in SQL Server format (.BAK file), encrypted, decrypted, and delivered via secure file share.

  • Multiple backups are not recommended and may incur additional charges.

  • Backup validation:

    1. We restore and verify the backup before we send it to you.

    2. Your technical team is expected to also restore and validate the backup using provided documentation.

Backup Restoration Guidance (Reference Only)

These instructions are provided as a reference only. We do not support installation, troubleshooting, or data mapping. Please confirm readiness for extract at least five business days in advance to ensure resource availability.

When a final database backup is provided, it is delivered as a .bak file in SQL Server format. This file must be restored within a SQL Server environment to access the data. While we do not assist with setup or database-level tasks, we will confirm the file’s integrity and successful restoration.

To support your internal IT team, general installation and restoration steps are outlined below:

  1. Install SQL Server Express.

    1. Download here: https://www.microsoft.com/en-us/sql-server/sql-server-downloads

  2. Install SQL Server Management Studio (SSMS).

    1. Download here: https://aka.ms/ssmsfullsetup

  3. Restore the .bak file:

    1. Open SSMS and connect to localhost\SQLEXPRESS using Windows Authentication.

    2. Right-click Databases > Restore Database…

    3. Select Device.

    4. Browse to and select the .bak file.

    5. Proceed through the restore dialogs.

    6. Once the file is restored, expand the database and view tables using Select Top 1000 Rows.

Data Destruction and Attestation

  • All your data, logs, and files are deleted.

  • Dedicated servers are not standard for Ripple Treasury Platforms on the shared solution. Legacy Ripple Treasury Platform setups may have dedicated servers.

  • On shared tenants (e.g., UK PROD), client separation is managed via separate databases and file directories.

  • Formal attestations are not standard and may be provided only upon request.

Operational Archive and Fallback

  • Any SharePoint-based archive that you manage are your responsibility. We don’t maintain or decommission your SharePoint archive.

  • You are encouraged to use the UI to retrieve any needed reports or documentation prior to decommissioning.

  • The backup .BAK file (if requested) serves as a fallback for data recovery.

Timing and Freeze Periods

  • Decommissioning must be completed prior to any scheduled change freeze.

  • UI access is typically retained until the freeze date.

  • We require 2–3 business days of lead time before the freeze to complete destruction.

Contingency Planning

  • If decommissioning can’t be completed before the freeze:

    • Operations may resume after the freeze period.

    • A contingency plan should be established to execute decommissioning post-freeze.

Optional 2-Step Decommissioning (Selective Offering)

In some cases, a 2-step decommissioning process may be offered based on contractual terms, risk profile, and operational dependencies. This approach includes:

  1. Point-in-time database snapshot:

    • Taken ahead of full decommissioning to support data validation or archival needs.

    • Delivered as a decrypted .BAK file via secure file share.

  2. Full decommissioning and destruction:

    • Includes service shutdown, job removal, data deletion, and server destruction.

    • Formal attestation may be provided upon request.

Risk Considerations

  • Splitting decommissioning into 2 steps introduces risk:

    • Data entered after the snapshot will not be captured.

    • Extended access to systems may delay final destruction and increase exposure.

    • Operational complexity may increase if timelines shift or freeze periods intervene.

Policy

  • This 2-step decommissioning is not standard and will only be offered to clients who meet specific criteria.

  • Requests for this approach must be reviewed and approved by the account team and relevant stakeholders.

Key Considerations

  • Point-in-time backups do not include data entered after the snapshot date.

  • Multiple backups are discouraged and may be subject to additional charges.

  • All actions should align with contractual obligations and internal risk policies.

Copyright 2025 Ripple Labs Inc.

Related articles