Terms & Conditions consent log

Introduction

In accordance with the April 2021 ruling from the Federal Court of Justice of Germany, whenever Solaris makes a change to a mandatory customer agreement document (e.g., the Terms and Conditions), Solaris must collect customers' express consent to the new document.

When this occurs, Solaris will provide you with information about the update. You must then prompt your customers in your solution to consent to the new Terms and Conditions (or any other such contract that they signed with Solaris) and record their consent using the terms and conditions consent log API. The same endpoints can be used for both persons and businesses.

note

This API should only be used for previously onboarded customers (unless otherwise specified by Solaris). The customer's initial consent to the T&Cs is recorded during the initial onboarding.

How Solaris communicates changes to the T&Cs

When Solaris wishes to change the T&Cs, Solaris' Legal department will reach out to partners via email with the following information:

  • A link to the new T&Cs document,
  • The document ID of the new T&Cs for use in the API (see below for IDs you can use for testing),
  • The deadline for customers to agree to the new T&Cs,
  • The date when the new T&Cs come into effect,
  • Information on which T&Cs have been updated (which product), and
  • Clear guidelines on the consequences to the customer for rejecting the new T&Cs (e.g., account termination) and what actions partners must take in this case.

What types of documents and changes are involved?

You must always go through the T&C consent log process when the change in T&Cs relates to material changes (that is, changes that concern the parties' main contractual obligations) or fees.

In contrast, this process will not be necessary in cases where T&C changes relate to changes in the law or court decisions or authorities' guidelines, or where they relate to non-material changes (i.e., changes that do not concern the parties' main contractual obligations) or redactional changes.

What if the customer rejects the new T&Cs?

The consequences of rejection by the customer depend on which document they reject and the specific changes involved in the update. In many cases, this may be an ordinary account termination (with two months' notice). Solaris will trigger the account closure process manually in these cases.

note

If a customer rejects the new T&Cs, Solaris will not block their account. Do not restrict their access to your application and their account. If a customer changes their mind and wishes to accept the new T&Cs, then please contact Solaris Customer Support.

General flow

  1. Solaris updates a customer agreement (e.g., the T&Cs) and communicates these changes to partners as described above.
  2. Your solution must display the new T&Cs to their customers when they log in and prompt them with the option to:

    • review the T&Cs (i.e., read the text and then leave the T&Cs window without taking a decision),
    • accept the T&Cs, or
    • reject the T&Cs.
  3. When the customer accepts or rejects the T&Cs, then your solution must record this instance and then send it to Solaris using the POST Create terms and conditions event method.
  4. Solaris will store this consent in its systems. You can retrieve records of who signed the new document by calling the GET List all terms and conditions events method.

    • You can filter the results of this method by user (filter[signed_by]) or specific document (filter[document_id]). See the API documentation link above for more information.

How to present a T&C update

When Solaris publishes an update to the terms and conditions, your solution must present this update to the customer at the time they log in to the app or web browser. Your solution must indicate that action is required on their part and must prevent them from continuing past this point until they accept, reject, or skip the T&C update (which should only be possible until the deadline).

If the customer has not accepted or rejected the T&Cs by the deadline, then your solution must prevent them from proceeding until they do.

Acceptance/rejection paths

If the customer accepts the new T&Cs:

  • You must record the date/time of consent, the product_name of the relevant product, and the UID of the document, and send this information to Solaris using the POST Create terms and conditions event endpoint.
  • Solaris treats this as a confirmation that the customer agrees with the new T&Cs. This approval cannot be revoked.

If the customer rejects the new T&Cs:

  • In your solution, you must inform the customer about the consequences of rejecting the new T&Cs and offer them another chance to accept.
  • if Customer still rejects the T&Cs, then record the date/time of rejection, the product_name of the relevant product, and the UID of the document, and send this information to Solaris using the POST Create terms and conditions event endpoint.

If the customer defers a decision on the new T&Cs:

  • Your solution must constantly remind the customer in the form of a pop-up screen that they must take action on the T&Cs.
  • If one month has passed since the initial email and in-app notification, then you must prevent the user from using your app/web interface until they either accept or reject the T&Cs.
  • If the customer reaches out to your customer service team to unblock the frontend, inform them that they must accept or reject the new T&Cs.
  • Note that the underlying product (e.g., account, card, loan) will not be blocked.

If the customer neither accepts nor rejects and the deadline lapses:

  • You must prevent the customer from using your app/web interface until they either accept or reject the T&Cs.
  • Submit the information about the customer's acceptance/rejection to Solaris using the API as described above.
  • Note that the underlying product (e.g., account, card, loan) will not be blocked.

Example document IDs for testing

You can use the following document IDs to test this API on Sandbox:

document_name document_id
General Terms and Conditions v1 30d2d84cdd04715871610a9046b2081atcdc
General Terms and Conditions v2 e295e7bd63c112a960e44dec1261785ctcdc
General Terms and Conditions v3 41d817d6fcb3ee492ddcb8197e0edbf9tcdc