Technical Reference Guide

1 About this Document

This document covers the infrastructure, technology, and processes surrounding the Ripple Treasury application. Application development is the heart of our business, and we invest resources into maintaining a secure, technology–forward environment to deliver the best solutions for managing your treasury while protecting your mission-critical data.

Topics covered in this document include:

• Ripple Treasury’s Global Presence

• Multi-Tenant SaaS

• Compliance

• Business Continuity and Disaster Recovery

• Security

• Development & Release Methodology

• Application Interfaces

2 Ripple Treasury’s Technology Focus

Treasury technology is changing at an ever-increasing rate and is more global than ever. Speed, accessibility, connectivity, and security are top priorities for our customers.

Ripple Treasury’s focus adheres to the following principles:

• “No Compromise” stance on quality: Ripple Treasury maintains a “zero defect” mindset when it comes to developing and deploying our software. We always strive to meet or exceed our SLA goals and ensure our client base experiences zero defects.

• Operationalize our standard Service Level Agreement (SLA) and Mean Time to Repair (MTTR): Ensuring that we maintain our standards of 99.9% uptime and RTO of 4 hours and RPO of 30 minutes.

• Strong governance on security and compliance: Security is one of the foundations of Ripple Treasury. We strive to safeguard our clients by following industry best practices and complying with standard frameworks such as SOC 1 Type 2, SOC 2 Type 2, PCI and SWIFT. Ripple Treasury continuously addresses global considerations and additional certifications as the landscape changes.

• Develop Ripple Treasury with innovation and technology leadership: Ripple Treasury aims to be on the front line of industry changes including bank APIs and newer messaging formats.

• Scalability: Ripple Treasury’s application is designed to be scalable to accommodate both high performance and large volumes.

• Connectivity: Connectivity is the heart of the Ripple Treasury system, and we are continuously improving and growing our global connectivity capabilities. While we can connect to virtually any banking system, we know that’s only part of the solution – back office integration is an increasingly important part of the equation. Through a vast library of APIs, along with FTP, SWIFT, and direct connections with your financial institutions, Ripple Treasury offers unparalleled integration.

• Ease of Implementation: Ripple Treasury provides a highly configurable solution, which can be deployed and implemented easily by the client, with minimal business interruption. Ripple Treasury provides a highly skilled implementation team, which will guide your organization through the configuration and setup of the Ripple Treasury application.

3 Statement of Ethics

Ripple Treasury’s management team strives to achieve a culture of integrity by clearly communicating expectations and maintaining a culture of accountability throughout the organization. We attract and retain the best treasury specialists and technology experts in the industry by ensuring an ethical and positive environment. Every Ripple Treasury employee is valued and given the support they require to reach their professional goals.

Ripple Treasury’s employee policies outline appropriate business and personal conduct in the workplace. New employees are required to review and sign-off on these documents to indicate that they have read and agree to comply with all the policies contained therein. All employees are required to review and sign-off on applicable policies on an annual basis. Failure to comply with any stated policy is grounds for disciplinary action, up to and including termination.

4 Office Locations

Ripple Treasury is geographically disbursed, with office locations in London, Sydney, Manila, and Chicago.

4.1 Office Access

Physical security at Ripple Treasury offices is governed by tools such as cameras, badge scanners, and other methods deemed appropriate. Employees must always wear badges. Tailgating, i.e., following another person into the building without running a badge through the card reader, is strictly prohibited. Badges are issued to new employees after completion of the necessary background checks and badges must be immediately surrendered upon separation from the company.

4.2 Visitors

Visitors are required to sign in at the reception desk and receive a visitor badge. When in the Ripple Treasury office, visitors are escorted and are required to surrender their badge when leaving.

4.3 Employee Workspaces and Machines

Employees should clear workstations at the end of every workday and lock any sensitive information in desk drawers. Any physical documents deemed not necessary to keep and potentially containing sensitive information must be securely shredded. Mandatory machine password locking is set by the administrator at the Windows Active Directory Group Policy level and occurs after 15 minutes of inactivity on all employee workstations.

4.4 Server Room Access

The server room is secured by electronic key card access, with a separate, pre-authorized access list, reviewed and approved on a quarterly basis. When access to the server room is required by individuals who are not pre-authorized (such as phone and CCTV support, electronic security vendors, etc.), access must be approved, and individuals must always be accompanied by an authorized user.

5 Data Center Regions

Ripple Treasury’s production environment is hosted in regional data centers. Each region has a primary and backup data center hosted by Microsoft Azure.

Primary and backup locations are geographically separated and are selected based upon Microsoft pairing recommendations.

United States

• Central – Iowa (Primary)

  • East 2 - Virginia

• EMEA

  • UK South – London (Primary)

  • UK West - Cardiff

• APAC

  • Australian East – New South Wales (Primary)

  • Australia Southwest - Victoria

• Canada

  • Canada Central – Toronto (Primary)

  • Canada East – Quebec City

Client data resides within the designated region and will not be removed from that region in any format without client consent. This includes database backups, imported and extracted files, and FTP processing.

Azure uses industry-leading security, leveraging the highest possible standards for physical location security (including biometric scanning, camera monitoring, and dedicated security staff present 24x7), intrusion detection, encryption, firewalls, and certifications, such as Service Organization Controls (SOC) 1 and 2 as well as Payment Card Industry (PCI) compliance. Microsoft data centers are Tier 4 in terms of physical security.

Ripple Treasury uses Rackspace for services that Azure cannot support. These currently include SWIFT connectivity, PCI card processing environment, and RSA authentication servers. The Rackspace environment has no public endpoints and is only accessible via VPN tunnels from selected office and Azure networks. Rackspace data centers are in Chicago and Dallas.

6 Multi-Tenant SaaS

Ripple Treasury’s network environments are designed for security, flexibility, and scalability. Ripple Treasury leverages Azure as an IaaS platform (Infrastructure as a Service), which means Ripple Treasury actively manages the service. Ripple Treasury’s internal network is managed by our IT team.

The SaaS model provides a wealth of advantages including:

1. Faster setup and more cost-effective. Ripple Treasury trains your team and helps configure the application, streamlining the setup and implementation of the Ripple Treasury application.

2. Tremendous scalability. Ripple Treasury uses an industry-leading hosting provider with data centers throughout the world and virtually unlimited scalability.  Connections are automatically routed based on traffic load to optimize security and performance. Any number of users may be logged on simultaneously with no degradation in reliability or performance.

3. Strongest reliability. Ripple Treasury provides 99.9% uptime, with automatic routing and failback capability in the unlikely event of an outage. Full backups are taken and verified daily.  Data centers are physically separated according to Microsoft pairing recommendations.

4. High security. In addition to our robust application security, we apply industry best practices and third-party recommendations to our servers, including IDS/IPS, WAF, file integrity monitoring, third-party software analysis, etc.  As leading data center providers, Azure and Rackspace apply the highest physical security standards available.  Anti-virus is applied to all servers.

5. Worry-free upgrades and maintenance. Ripple Treasury manages everything behind the scenes – with releases and patches applied during defined maintenance windows on Saturday evenings.  We provide detailed training and documentation so you can use new features right away.

6. Since the application is browser based, you can securely access Ripple Treasury from anywhere – not just the office.

7 Multi-Tenant Implementation

The Ripple Treasury application uses physically structured and separated tiers, each with highly segregated functions, including:

1. DMZ

2. Application

3. Data

4. Bastion

5. Infrastructure

6. Security

The multi-tiered approach provides high security and reliability, as well as the following advantages:

1. Flows between each tier are controlled. Firewall rules limit traffic between tiers to permitted ports and protocols. This isolates the sensitive tiers very deeply in the architecture.  Firewall rules deny by default.

2. Bastion servers are in place as the entry point for any maintenance activity. These machines restrict external access to the data center servers to authorized Ripple Treasury personnel.  Only VPN traffic from Ripple Treasury offices is allowed to these servers and multi-factor authentication is required.

At the application level, the web and application tiers are independent, and the functional application layers are logically separated with distinct “trust layers.”

Hardware is shared across clients, with each client having their own distinct database on shared SQL database servers. The Company ID provided on login is used to identify the appropriate database connection string in the backend. This guarantees that there is no data leakage between clients.

8 Environment Topology

Client facing environments are on different networks to office networks. The office network is maintained by IT while the client facing environment is activity managed by the DevOps team. Different domains are used for the Azure, Rackspace, and office networks.

For security and performance, our internal network segregates corporate administrative network functions from application development functions. Remote access is secured via an encrypted Virtual Private Network (VPN). Access to the underlying SQL database is restricted to technical personnel.

All server access by the team is logged and reviewed daily. Access logs are reviewed daily by the Security & Compliance team. Access to servers is limited to DevOps and IT.

9 Data Center Compliance

Azure is widely regarded to be one of the most comprehensive set of cloud services, offering local deployment while complying with a comprehensive range of global standards including, but not limited to:

ISO 20000 (IT Service Management)

• ISO 27001 (Information Security Management)

• PCI-DSS Level 1 (Payment Card Industry Data Security Standard)

• ISO 9001 (Quality Management)

For a full list of Azure compliance standards, please visit:

https://www.microsoft.com/en-us/trustcenter/compliance/complianceofferings

Rackspace complies with several global regulations and compliance certifications. Certifications include, but are not limited to:

• ISO 27001 (Information Security Management)

• SOC 1, 2, and 3

• PCI DSS Level 1 (Payment Card Industry Data Security Standard)

• ITAR

• HITRUST

For a comprehensive list of Rackspace compliance standards, please visit:

https://www.rackspace.com/compliance

10 Service Organization Controls (SOC) Certification (1 and 2)

Ripple Treasury has selected RSM US, LLP to certify compliance with SOC 1 Type 2 and SOC 2 Type 2 standards..

SOC 1 reports are specific to the organization's internal controls and relevant to financial reporting or Internal Controls over Financial Reporting (ICFR). SOC 1 engagements are performed in accordance with the American Institute of Certified Public Accountants (AICPA) Statement on Standards for Attestation Engagements (SSAE) 18 standard.

Whereas SOC 1 focuses primarily on financial controls and reporting (to mitigate risk and protect against fraud), the SOC 2 report is more security-oriented and focuses on the security and availability categories.

When combined, clients can rest assured that the proper controls are in place to ensure the integrity of their financial reporting as well as the integrity and reliability of all systems related to the processing and retrieval of their data. Ripple Treasury knows that trust is crucial to our clients; therefore, we maintain ongoing certification for both standards.

Starting in 2020, RSM will issue both SOC 1 and SOC 2 reports on a rolling 12-month period with period end dates of March 31 and September 30. Bridge Letters are available upon request.

11 PCI Compliance

Ripple Treasury is PCI-DSS certified.  All servers and related hardware through which client data may pass is included within scope for PCI compliance, including our internal network and production data centers.

Ripple Treasury conducts a self-assessment questionnaire (SAQ) each year.  A third-party auditor (RSM US, LLP) conducts Ripple Treasury's quarterly vulnerability scans, internal network penetration test, external network penetration test, and web application penetration test as a part of Ripple Treasury's compliance with PCI.

Firewall and server event logs are stored to PCI requirements for at least 1 year with Alert Logic and reviewed daily.

Credit card transactions should not be processed through Ripple Treasury without an appropriate contract as processes need to be explicitly implemented for the processing of such data.  

12 GDPR and Privacy Regulations

As a data processor, Ripple Treasury works in conjunction with our clients (data controller) to abide by GDPR regulations. Ripple Treasury’s Privacy Policy incorporates relevant aspects of GDPR, while policies are additionally available regarding the proper removal of data upon a data subject’s request. The model clauses as well as data processor and data controller responsibilities are outlined within the Ripple Treasury agreement.

Ripple Treasury’s Security & Compliance team review applicable privacy regulations for all geographic regions as we become aware of them. Where applicable, these regulations are applied into global policies.

13 SWIFT (Society for Worldwide Interbank Financial Telecommunication)

Ripple Treasury offers SWIFT Alliance Lite2 bank connectivity to clients as an option. To ensure our SWIFT offering aligns with SWIFT security objectives and requirements, we are audited by the SWIFT organization every three years. The audit focuses on a set of mandatory core security standards as well as an assurance framework referred to as the Customer Security Program (CSP). The SWIFT certification provides yet another layer of confidence to our clients, regardless of whether they utilize the SWIFT AL2 offering.

14 Intrusion Detection and Prevention

Alert Logic provides IDS/IPS services and 24/7 security monitoring. Alert Logic monitors Ripple Treasury’s network and raises incidents to Ripple Treasury’s attention via email and/or phone depending on the severity.

15 Disaster Recovery

Ripple Treasury knows that access to the application is critical to our clients in conducting their daily business. We have created processes to ensure that, in the event of a serious physical disaster and/or security incident, we can maintain the availability of the application and support staff to ensure clients encounter little or no interruption.

By Ripple Treasury policy, failover testing is formally conducted at least twice per year. It is an execution of a series of steps designed to verify that Ripple Treasury can handle specific scenarios relating to failures of devices, data centers, or services.

All data centers are consistent in design. As such, the only distinction between environments is that a client database will be accessible in one location and not accessible in the other until failover occurs. A full data center failover is a manual process in as much as a decision is made to initiate failover, as opposed to automatically failing over based on set events. The exact nature of the process depends on whether the primary databases are still available, as the access to those databases will determine whether any data loss occurs.

There are two repositories of data within the environment – file servers and database servers. File servers are synchronized across all instances using DFS-R (Windows Distributed File System Replication) within a given region. Database servers use two techniques to maintain consistency:

1. AlwaysOn – a SQL Server technology used between database servers within a data center. Transactions are written to all servers within a region simultaneously such that they can failover almost instantly with no loss of data.

2. Log Shipping – a custom version of SQL Server technology used between database servers within a region in different data centers. Log records are backed up every 10 minutes, copied across to the other data center and restored to the target database.  This database is not available for queries in recovery mode but can easily be brought online with a simple command.  This technique drives the RPO objective of 30 minutes.

NOTE: It is Ripple Treasury’s intent to move away from Log Shipping during 2020 in favor of AlwaysOn in asynchronous mode between data centers. This should provide faster failover and a decreased level of data loss.

16 Business Continuity

The principal objective of the business continuity plan is to develop, test and document a well-structured and easily understood plan. This will help the company recover as quickly and effectively as possible from an unforeseen emergency which may interrupt information systems and business operations. The business continuity plan is to be kept up to date to consider changing circumstances. The plan will be reviewed and updated (if appropriate) at least annually.

Business Continuity is tested at least once every 12 months to ensure that it can be implemented in emergency situations and that the management and staff understand how it is to be executed.

17 Recovery Objective

Interruptions of service are defined by two factors: Recovery Point Objective (RPO) and Recovery Time Objective (RTO):

• Recovery Point Objective (RPO): Refers to the time between data protection events and indicates the amount of data at risk of loss during a disaster recovery. Ripple Treasury’s RPO is currently 30 minutes, or as stated in the contract.

• Recovery Time Objective (RTO): The minimum time services must be restored after a disaster to avoid an unacceptable break in business continuity. Ripple Treasury’s RTO is four (4) hours, or as stated in the contract.

18 Backup

Full backups are taken and verified daily. Backups are retained in geo-redundant storage. These backups are stored in an Azure storage account subscription in an encrypted form and retained for at least 30 days. They are tested for restorability to ensure no corruption.

19 Application Security

The highest security standards are built into the Ripple Treasury application, from login, to hosting, to user management, to funds transfers, to communication with banks, to the hosting of the application itself. Security is a dynamic concern and requires careful consideration from every angle.

19.1 Login Security

The most critical component of application security is the login process, as login security is the gateway to the application. Ripple Treasury provides several standard and optional ways of ensuring only authorized users are allowed in.

Ripple Treasury fortifies logins with the following features:

• Single Sign On (SSO): Ripple Treasury supports identity provider initiated SAML2.0.  

• Multi-Factor Authentication: MFA authenticates using an additional piece of information.

Ripple Treasury provides two options for multi-factor authentication:

• RSA SecurID: A hard token method providing a unique, temporary security code required to access the application.

• Symantec VIP: A secure application/soft token available on your phone or tablet.

• IP White Listing: Allows clients to specify the addresses allowed to access the Ripple Treasury application. For organizations concerned about the locations from which users are accessing the application, IP white listing is a great option.

19.2 Password Security

Access to the Ripple Treasury application is secured by strong password standards. Initial passwords must be changed after login and may not contain the user’s account name, full name, numbers associated with personal information, or common words. Commonly used sequences or repetition of the same character is also prohibited. Ripple Treasury guidelines suggest that passwords must be at least fourteen (14) characters in length and meet industry-standard complexity requirements. Passwords expire after 90 days, and the previous eight (8) may not be re-used. Password standards are subject to change at any time based on the latest security standards. These default guidelines may be configured to accommodate client requirements.

Passwords are not stored within the Ripple Treasury application. Only the salted hash of passwords is stored.

19.3 Vulnerability Scans

Ripple Treasury conducts vulnerability scans on a weekly basis against both private and public endpoints. In addition, RSM US, LLP conducts quarterly vulnerability scans as part of Ripple Treasury’s compliance with PCI.

19.4 Static Code Scans

Veracode static code scans are conducted as a part of the build process. This ensures that new features and functionality do not introduce vulnerabilities into the Ripple Treasury application. Scan results are regularly reviewed, and actions are taken to address any potential issues.

20 Data Security

Data is only as secure as its weakest access point and as such, Ripple Treasury encrypts end to end (at rest and in transit) using the following protocols:

• Transport encryption is via TLS 1.2, HTTPS, FTPS, and SFTP.

• Database encryption using SQL TDE AES 256.

Encryption follows generally accepted standards, including AES 256 and SHA 2. Message signing and encryption use PKCS and PGP, while encrypted storage and SMB 3 is in place for file shares.

21 Security Incident Protocol

Ripple Treasury has developed a comprehensive Security Incident Protocol. A formal assessment is undertaken to determine the existence of an incident and whether the Security Incident Protocol should be implemented. The Security & Compliance team owns the Security Incident Protocol.

Per Ripple Treasury’s MSA, a Security Incident is defined as an actual or Suspected unauthorized acquisition of Customer Data that compromises the security, confidentiality, or integrity of Personal Information maintained by Provider (Ripple Treasury) for Customer. “Suspected” shall mean that the Provider’s IT Systems have reported a compromise or have behaved in such a manner as would lead a careful and knowledgeable IT professional to investigate the cause for such behavior.

The Security Incident Protocol covers all essential and critical infrastructure elements, systems and networks, in accordance with key business activities. The protocol incorporates appropriate elements of the Disaster Recovery and Business Continuity Plans as well as the resolution of Severity Level 1 and 2 issues.

The Security Incident Protocol will be periodically tested to ensure that it can be implemented in emergency situations and that all employees understand how it is to be executed. If Ripple Treasury experiences a Security Incident during the year, the protocol will not be formally tested at the discretion of the Security & Compliance Team.

The Security Incident Protocol will be updated periodically to consider changing circumstances.

The security incident protocol covers the full lifecycle of an incident from identification through recovery and lessons learned/post-mortem.

• Identification – Determine and classify the type of incidence.

• Containment – Stop the damage and prevent further damage.

• Eradication – Completely remove all malicious content; restore all affected systems. Clean all affected systems and, if necessary, re-image affected applications and operating systems.

• Recovery – Restore affected systems to the network and all functionality.

• Lessons Learned – Review all documentation related to the incident. Make changes to processes and software/hardware environments as needed.

22 Development Methodology

Ripple Treasury’s software development lifecycle is based on an agile development methodology, with a focus on continual enhancement and acceleration of the delivery cycle.

Ripple Treasury follows agile development practices.

Agile development:

• Accelerates the process of enhancement design, development, and delivery while providing a clear and common understanding of current are future work priorities and backlogged items.

• Increases client engagement, and small agile team structures promote constructive workflows supported by time-boxed agile ceremonies.

• Focuses on transparency, continuous feedback loops, and adaptation as it applies to people, process, product and architecture.

Client Benefits

Ripple Treasury’s focus on Agile provides several Client-focused benefits:

• Current technology. As a client, you are assured of having the latest features as they become available.

• Improved performance. While our development sprints allow for the continual inclusion of new features, we continually make “behind the scenes” changes to enhance and support our infrastructure.

• More manageable, predictable releases. More frequent releases mean less work for the client, as releases are incremental, predictable, and introduce new functionality in small pieces. Changes are gradual and occur over the year rather than an annual “big unveiling.”  Functionality is available to all clients subject to license and is controlled via configuration options

• Greater client communication. Client involvement is vital. Regular communication between Ripple Treasury and our clients ensures client focus and quick implementation of suggestions when possible.

• Extensive testing. Before going live, releases are tested by our Quality Assurance team throughout the development lifecycle.

• Transparency. All changes are communicated in release notes and supplemental documentation.

22.1 Programming Environments

The following environments are used in the development and support of the Ripple Treasury application.

22.1.1 Development

Ripple Treasury maintains development environments at our corporate offices. The hardware and software is maintained by Ripple Treasury staff and our IT team. The network is internal, firewalled, encrypted, and is not accessible to anyone outside the company.

Developers use professional source code control systems to check code in and out of the source control repository. Code is branched for each version that is released. Core development for the next release continues on the main track while maintenance development is done on the branched code.

Ripple Treasury leverages several tools to aid in product development:

• Programming Stack: Ripple Treasury’s development team focuses on the “Microsoft Stack,” which includes SQL and .NET to deliver the most robust solution in terms of security, availability, and performance. We also incorporate certain client-side JavaScript libraries to enable a rich user experience in the browser.

• Microsoft Azure DevOps (ADO): used to track product ideation, plan, organize, and develop enhancements, technical debt and bugs.  Detailed documentation is linked to the tickets in ADO.  Work is captured in the form of epics, user stories and bugs, which get prioritized and assigned to a sprint. ADO’s collaborative features allow for full transparency, permitting users to view sprint and issue status at any point in time.  All changes, dependencies, documentation, comments, and work activity are captured for tracking and review.

22.1.2 QA

This environment is where the QA team performs its testing for product enhancements, bug fixes, and other changes to the product. This environment allows Ripple Treasury to test in an environment similar to production to ensure accuracy in the application testing.

Quality Assurance is fully integrated into the SDLC. A suite of fully automated regression tests are run at several intervals throughout the cycle along with a select group of manual regression tests.

In addition to the QA cycle, automated smoke tests are performed to ensure correct functionality of key components. The development team integrates automated unit testing into builds to ensure no functionality is broken as changes are implemented. Ripple Treasury also conducts manual unit testing to verify changes.

Client data is never used in Quality Assurance testing. There are multiple phases of Quality Assurance testing prior to deployment to production. This aligns with Ripple Treasury’s commitment and target to introduce zero net-new defects.

22.1.3 Production

All changes to the Ripple Treasury application are fully tested in development and QA before released to production in accordance with the Software Development Lifecycle (SDLC).

22.2 Sprint Details

Release deployments occur every 8 weeks. Release cycles are made up of four sprints. There are three two-week development sprints, focused on new features, functionality and enhancements, with one two-week hardening sprint, focused on quality, technical debt and bug fixes. Prior to the deployment of a release to client facing environments, appropriate sign-off is required. Releases are applied during defined maintenance windows on Saturday evening.

22.3 Change/Patch Management

Ripple Treasury has established a formal policy and detailed procedures concerning security patch management. It is evaluated on an annual basis to ensure its adequacy and relevancy regarding Ripple Treasury’s needs and goals.

Note that this policy does NOT apply to scheduled updates of the Ripple Treasury application.

22.3.1 Operating Systems

Ripple Treasury will only use operating systems supported by the vendor. Only operating systems under mainstream support should be used. All operating systems should be patched on a monthly basis with fixes released by the vendor. Specific patches may be excluded if they are deemed a significant risk, or if problems have been identified. Certain critical vulnerabilities may require a faster response and should be applied as soon as that fix has been verified to not cause additional issues. Ripple Treasury will work expeditiously to implement critical vulnerabilities as quickly as possible. Non-critical items will be deployed after the updates within the patch have been verified.

22.3.2 Software / Applications

Software installed on Ripple Treasury servers will, from time to time, be subject to updates and patches released by the appropriate vendor. These updates should be reviewed on a regular basis (by the DevOps team and IT) in order to identify the criticality and risk (of applying or delaying the patch). Ripple Treasury will work expeditiously to implement critical vulnerabilities as quickly as possible. Non-critical items will be deployed after the updates within the patch have been verified.

22.3.3 Third Party Tools

The Ripple Treasury application may, at the discretion of the development team, make use of third-party tools and libraries. These products should be reviewed at least annually in order to identify whether updates are necessary. The use of third-party tools and libraries must be approved by management prior to use.

22.3.4 Timing

Ripple Treasury will rely on external assessments of vulnerabilities or patch criticality but may adjust the assessment based on mitigating factors.

Copyright 2025 Ripple Labs Inc.