Breaking Change Policy

Introduction

This document outlines the Galileo breaking change policy, intended to set mutual expectations between Galileo and our clients regarding our APIs, RDFs, file formats, and protocols.

Overview

Galileo is on a mission to continuously improve the products and services available to our clients. Our goal is to minimize client impacts when introducing enhancements, new product features, and capability improvements. However, from time to time, a change may require client action to prevent existing capabilities from breaking. This document outlines what Galileo considers a breaking change versus a non-breaking change and how we communicate with clients in the event of a breaking change.

Definitions

Non-breaking changes

Non-breaking changes are code changes that are not expected to be disruptive to clients, who can adapt to these changes at their own discretion. Clients should be able to handle these changes without any notice from Galileo.

Examples of non-breaking changes

• Adding a new, optional, input field to a request that does not change the behavior of existing fields
• Adding a new required field that has default values
• Adding a new response code for new functionality that does not impact existing response codes
• Adding a new field or data element to an existing response payload returned from Galileo services that does not change the meaning of existing fields
• Adding an optional request header
• Adding a new endpoint
• Removal of an optional request header
• Updating a parameter description
• Updating sequence numbers in accordance with Nacha rules
• Non-breaking changes in RDFs:
  • Updating the layout by adding a new column or rearranging the existing ones, while keeping all the original information exactly as it is. However, in the case of a fixed-width file, this would be considered a breaking change.
  • Adding new data without changing the file structure (e.g., adding new program records to a file)
  • Changing the letter casing of a field name (e.g., changing a lowercase field name to uppercase or camelCase)
  • Adding trailing spaces or removing them when they are not meaningful
  • New field semantics (e.g., adding a new value, such as Closed, to an existing Account Status field)
  • Enhancing data files by populating existing fields that previously defaulted to null or blank. (e.g., populating the batch header for outgoing ACH transactions when it was previously only populated for incoming ACHs)

Breaking changes

Breaking changes are code changes that require clients to take action to avoid potential disruption. Galileo communicates these changes to clients before rolling out these changes.

Examples of breaking changes

• Requiring a new input field
• Making a previously optional input field a required field
• Updating an existing field or data element in an existing response payload returned from Galileo services
• Changing the agreed details of a file exchange (e.g., file name patterns, field widths, field data types, ordering of fields, format changes, adding/removing fields in fixed width files, line endings in ACH files)
• Changes to request/response headers
• Updating existing required product configuration parameters
• Breaking changes in RDFs:
  • Removing an existing field from the RDF output
  • Updating or changing the primary key used by downstream consumers
  • Renaming a field (e.g., changing AcctId to AccountId)
  • Changing the data type of an existing field (e.g., changing char to num)
  • Updating field semantics (e.g., updating Status values from Y/N to Yes/No) or updating the logic for how we calculate the value for a field
  • Modifying partitioning or file-processing logic (e.g., changing quoting rules or compression format)
  • Changing filenames or naming conventions
  • Modifying the schema of a fixed-width file (e.g., changing field widths, data types, field order, format changes, or adding or removing fields)
  • Updating a file trailer

Communication

We will communicate breaking changes to clients before rolling out these changes. However, if a change is necessary for critical legal, security, or compliance concerns, we will deploy a breaking change without prior notice.

For all other breaking changes, we will communicate with clients before the release. Communications will include supporting documentation and allow time for client validation before changes are deployed to the production environment. We will share notifications through existing channels, such as the product roadmap, monthly updates, and client meetings.