Managing product terms and conditions

Terms and conditions can be associated with a product or a product relationship in order to describe the rules and details governing the product. Terms and conditions can also be associated with an agreement (or contract) business entity from the Account domain.

Examples of terms and conditions include the eligibility rules for selling a product to a customer or disclosures.

Terms and conditions are managed in the TermCondition entity. The transaction reference documentation describes how to add, update and inquire on terms and conditions and how to attach them to other entities such as products, product relationships and agreements.

Note: It is possible to maintain a product or product relationship's terms and conditions by using the coarse grain addProductInstance, updateProductInstance and getProductInstance services.

The following describes the features that can be utilized in managing terms and conditions:

The static text of terms and conditions can be captured in the description field of the TermCondition entity and can be maintained in multiple languages.
TermCondition entities can be reused between different products. This can be achieved by associating the same TermCondition entity with multiple products or product relationships.
Terms and conditions support a hierarchical structure. Each TermCondition entity can have multiple nested sub-conditions, also represented by the TermCondition entity. Each TermCondition entity can only have one parent. Only the top-most TermCondition entity can be associated with other business entities such as products and therefore sub-conditions cannot be directly related to business entities.
Terms and conditions can be categorized by usage type to describe the purpose of the condition. Examples include Value Package Eligibility, Product Disclosures, and Rate.
Terms and conditions can have attributes. Attributes can be used as parameters to external rules that govern terms and conditions. For example, an eligibility rule for a particular product might have a condition stating that the customer must have an account with a valid status. The attributes of this condition would contain the valid statuses.
Terms and conditions can be overridden. For example, a TermCondition defined as part of a product can be overridden once an agreement has been captured as a result of selling the product to a customer. In order for a TermCondition to be overridden then the overrideIndicator must be set to yes.

The following example shows the simplified terms and conditions for a consolidated statement service. This service is defined as a product. Customers can sign up for the service to receive a single statement that contains all of their selected accounts.

Graphic representation of simplified terms and conditions for a consolidated statement service.

This example describes the conditions that must hold true for a customer to receive a consolidated statement. The conditions are:

They must have a valid anchor product.
In addition to having a valid anchor product, they can have additional participant products.
For any Personal Checking or Savings products they want on the consolidated statement, they must be in a valid role on the account (owner, co-owner, guardian, or trustee) and the account must be in a valid status (open, inactive, or credits only).
For any Investment products they want on the consolidated statement, they must be in a valid role on the account (owner or co-owner) and the account must be in a valid status (open or inactive).

These conditions and their attributes can be used by an external process (or in this case, the Account domain) to govern the consolidated statement service sold to the customer. For example, the Account domain can be used to ensure the customer is in a valid role for each account on the consolidated statement. If at any point in time they are no longer in a valid role, then the Account domain can react accordingly.