MATTR Service Level Agreement

Service Commitment

We pride ourselves on providing an outstanding customer experience. This starts with the way we’ve designed our Services and extends to the way we work together with our customers during and after deployment. We will use reasonable efforts to ensure that each Service to which this SLA applies is Available at least 99.90% of the time during any calendar month (the Service Commitment). If we do not meet the Service Commitment for a Service, you may apply for a Service Credit (as described below). Service Credits are available for Severity Level 1 Incidents that impact Availability.

Service Credits

If a Service does not meet the Service Commitment in a calendar month, the Service Credit will be equal to a percentage, as specified in the following table, of the sum of the monthly recurring fees and usage fees, and excluding one-time charges, for that Service in that month (total monthly charge). If recurring charges and usage charges for a Service are specified annually, the total monthly charge will be the sum of the annual recurring charges and usage charges divided by 12. If a Severity Level 1 Incident spans multiple billing periods, the Service Credit will be calculated based only on the total monthly charges for the billing period in which that Incident commenced.

If you are eligible and apply for any Service Credits, we will provide them only as credits against future Services payments otherwise due from you. Service Credits will not entitle you to any refund or other payment from us. A Service Credit will be applicable and issued only if the credit amount for the applicable calendar month is greater than one dollar ($1 USD). The Service Credit must be used within twelve months of issuance and refunds will not be provided. Service Credits may not be transferred or applied to any other Account. For any Unavailability or other failure to meet the Service Commitment, your sole and exclusive remedy is the receipt of a Service Credit (if eligible) in accordance with the terms of this SLA.

Service Credit Request and Payment Procedures

To receive a Service Credit, you must submit a claim by sending an email to accounts@mattr.global. To be eligible, the credit request must be received by us within 30 calendar days after which the incident occurred and must include:

1. the words “SLA Credit Request” in the subject line;
2. the dates, times, and the regions of each Incident that you are claiming caused an Unavailability; and
3. the affected aspect of the Service in accordance with the categories outlined in the Incident Management Table below.

If the Unavailability in your request is confirmed by us and reflects Availability that is less than the Service Commitment, we will provide the Service Credit against the fees owed by you in the next billing period. We do not have to provide a Service Credit if you fail to submit the Service Credit request and other information in accordance with the terms of this SLA.

Incident Management

If an Incident (as defined below) is detected by us or reported by you, we will at our discretion confirm the Severity Level, make reasonable efforts to remedy it, and adhere to the response and resolution times set out in the following Incident Management table. The following categories must be used when you log an Incident.

Incident Management Table

Our standard target response and update times are outlined in the following Response Table. This is based on business hours (9am to 5pm New Zealand Time) on Working Days.

Response Table

We may by written agreement offer and provide you with enhanced SLAs. Enhanced SLAs do not form part of this SLA. If you require an enhanced SLA please contact us to discuss your requirements.

Exclusions

The Service Commitment does not apply to any Unavailability, suspension or termination of the Services, or any other performance issues related to the Services:

1. caused by factors outside of our reasonable control including any Force Majeure Event or Internet access or related problems beyond the demarcation point of the Services;
2. that result from your actions or inactions or are caused by any third-party software or infrastructure (e.g. third-party ledgers) you have chosen to use with the Services;
3. that result from your or a third-party’s equipment, software, network or other technology (other than third-party software and equipment within our direct control);
4. that result from you not following our reasonable directions or the best practices and configuration described in MATTR Documentation;
5. occurring during planned maintenance; or
6. arising from our suspension or termination of your right to use the Services in accordance with the Agreement.

If Availability is otherwise affected in a way that materially impacts you then we may, at our discretion, issue a Service Credit to you.

For clarity, the Service Commitment does not apply to Preview Services, the Mobile Wallet (including SDK and UI Reference Implementations), the Site, or the Self-Service Billing Portal.

Planned Maintenance

Our policy is to minimize down-time and planned maintenance impact on our customers. We will use reasonable efforts to minimise the impact of situations where downtime is needed (for example, planned system maintenance and specific release upgrades).

We will communicate planned system maintenance activity at least eight hours in advance (typically seven days in advance). In very rare cases (for example, critical security patches) we may need to undertake emergency maintenance without prior notification.

We aim to undertake planned system maintenance outside the core business hours for your Region.

Service Credits are not available for any Unavailability resulting from planned maintenance.

Release Management and Naming Conventions

We use standard semantic versioning for our releases (X.Y.Z) as described in the following list:

1. Major Change. X represents a release with a “Major Change”. This could include, for example, the introduction of a significant new feature, new version of an API or removal of an API from the codebase (previously announced and marked as End of Life).
2. Minor Change. Y represents a “Minor Change”. This could include, for example, new functionality added, changed, or marked as planned for retirement (while maintaining backward compatibility).
3. Patch Change. Z represents a “Patch Change”. This is primarily used for the deployment of fixes.

For each release, we will communicate what is new, what has been fixed, what has been improved, what has been Retired and what has reached End of Life. We will make reasonable efforts to deploy all releases in a manner that is as seamless to customers as is practical.

The day-to-day operation of our infrastructure to the Services is not restricted by the release management conventions. We reserve the right to make changes outside of the release cycle in order to maintain the health and availability of our Services.

Version and Feature Support

We will always support one current version of our public cloud offering, and we will conduct upgrades to that version.

When we introduce a new version of a feature or API, we will mark the existing version as “Retired”. Retired product features and APIs are backwards compatible until they reach End of Life, at which point they are no longer supported and will be removed from the platform.

We do not allow new customers to use Retired features or APIs. For Retired features and APIs, we will not actively enhance them , and will only apply critical security fixes.

We will provide you with notice of our intent to remove a Retired feature or API from the platform, at least 6 months prior to its removal (at this point, it is “End of Life”). The End of Life notice may be provided at the same time as the feature or API is first marked as Retired, or the feature or API may be Retired for a period before we notify its End of Life, in which case it will continue to be retired for at least 6 months from that End of Life notification.

We understand that the upgrade of features can be disruptive. If the proposed retirement timeframe is problematic for you, you may notify us within 30 days after receiving the End of Life notice, in which case, we will endeavour to offer you reasonable migration options.

Breaking Changes and API Backwards Compatibility

A “breaking change” is a change to our Services that may require you to change your application for it to continue to work. Breaking changes include, for example, the removal or change of intended functionality of an API endpoint, the removal or changing of the data type of a request parameter, removing or changing the data type of a response property, or adding a mandatory request parameter.

Changes that are not breaking changes include, for example, adding new API endpoints, optional request parameters to existing API endpoints, the absence of a value or a default value (as appropriate) that will maintain prior behavior, adding new response properties to existing API endpoints, adding new values for existing parameters and properties that have enumerated sets of values, changes to the order of response properties, changes to error messages, fixes to HTTP response codes and error codes from incorrect code to correct code, and adding new optional HTTP request or response headers. Resource and rate limits, and the default and maximum sizes of paged data out of scope of the APIs, and may change.

An API is backwards compatible if an application written against one version of that API will continue to work the same way, without modification, against future versions of the API.

Excluded Services

The following Services are not subject to the terms of this SLA. Service Credits and Service Commitments are not available for these Services:

1. the Customer Portal;
2. the MATTR Site;
3. any Services supplied during a trial period; or
4. Services excluded from this SLA under applicable Service Terms, such as Third Party Components.

Platform Protection

To ensure optimal experience for all our customers, our APIs are subject to rate limiting. These limits help to mitigate against denial-of-service attacks, robots and any other form of intended/unintended excessive load on the platform.

We understand that some customers may need to perform load tests against the platform. To ensure we maintain quality of service for all our customers, if you need to undertake load testing please contact us in advance so we can discuss how we can best address your needs.

Because penetration testing could interfere with the use of our Services by our other customers, you must not perform or permit penetration testing without prior agreement.

We are also happy to share our internal testing and audit reports on request.

Security

For further information on our security policy and practices, including access, physical, data, server and hosting security, please contact us.

Definitions

1. Unavailability: means no eligible requests to the Service can be executed due to a Severity Level 1 defect.
2. Availability: means the Service is not experiencing Unavailability. Only Severity Level 1 Incidents impact availability.
3. Incident: means any Service-affecting issue having Severity Level 1, Severity Level 2, Severity Level 3 or Severity Level 4, each as categorised in the Incident Management table.
4. Force Majeure Event: means any fact, matter or circumstance described in clause 19.4 of the Customer Agreement document.
5. Service Commitment: has the definition set out in the paragraph headed ‘Service Commitment’.