What on Earth is AA?

At some point in your T24 career, someone said the words “Arrangement Architecture” at you. You nodded. They continued. You nodded again. The meeting ended. You went back to your desk and typed “what is AA in T24” into Google, which returned the Alcoholics Anonymous website, two LinkedIn posts from people who clearly didn't know either, and a Temenos documentation page that opened with the sentence: “The AA module provides a flexible framework that allows the creation of new Temenos Transact modules.”

Helpful. Cheers.

This article is the thing that should have existed when you started. By the end of it, you will understand what AA actually is, why it works the way it does, and why half the confusion around it comes from the fact that it uses the same words to mean slightly different things at different levels of a hierarchy. That last part is intentional. It is also, frankly, a choice.

What AA actually is

AA is the product engine in T24. If your bank runs mortgages, personal loans, savings accounts, current accounts, asset finance, or deposits through T24 — they are almost certainly running through AA.

Before AA existed, T24 had separate applications for each product type. Loans lived in LD. Money markets in MM. Deposits in their own world. If you wanted a new product type, you needed new code. Every bank ended up with a slightly different implementation. Upgrades were unpleasant. The Temenos product catalogue was quietly becoming ungovernable.

AA was the answer to a sensible question: what if, instead of separate applications for every financial product, we built a single configurable engine that could power all of them?

The idea is that a mortgage and a personal loan are not fundamentally different things. They both involve money going out, interest accruing, and money coming back in. The differences — rate types, fees, repayment schedules, early redemption penalties — are configuration, not new code. So instead of writing a new application for each product, you configure AA components to define the behaviour you want.

In theory: elegant. In practice: you have just inherited someone's product hierarchy from 2011 and nobody wrote anything down.

The building blocks

AA has a small vocabulary you need before anything else makes sense. The documentation introduces all of these at once, which is why most people's eyes glaze over. Here they are one at a time.

Product Family

A Product Family is a grouping that products inherit from. Think of it as a template at the top of a hierarchy. A bank might have a Family called RETAIL-LENDING that contains all the common behaviour shared across personal loans, mortgages, and overdrafts. Every product in that family inherits those defaults.

Families can inherit from other families. This is powerful. It is also how you end up with a six-level inheritance chain that nobody alive can fully explain.

Property Class

A Property Class is a category of behaviour. Not the specific configuration — the category. Examples:

• Interest — controls how interest is calculated and accrued
• Account — controls the creation of the underlying T24 account record
• Accounting — controls how accounting entries are generated
• Charges — fees, penalties, and other charges the product can apply
• Balances — how balances are tracked and reported

If you want a product to charge interest, it needs an Interest Property Class. The Property Classes you include define what your product is capable of.

Property

A Property is a specific instance of a Property Class. If Interest is the category, then STANDARD-INTEREST-CALC might be a specific Property that defines a particular way of doing interest calculation. A product can have multiple Properties of the same class — an overdraft might have a base interest Property and a penalty interest Property, both of the Interest class.

This is the first place people get confused: Property Class ≠ Property. The class is the type. The property is the implementation of that type.

Product Condition

A Product Condition defines the default values for a Property within a specific product. This is where you set things like the default interest rate, the default repayment frequency, the default charge amounts.

Here is where it gets interesting. Some of those defaults can be overridden at the arrangement level — meaning a banker can negotiate a better rate for a specific customer. Others are locked. This balance between what the product owns and what can be negotiated is called scope, and getting it wrong is the source of a significant number of support calls.

Arrangement

An Arrangement is a live instance of a product for a specific customer. When a customer takes out a mortgage, what gets created in T24 is an Arrangement. It references the product it came from, inherits the Product Conditions as its starting point, and then carries any negotiated values agreed at the time of booking.

Every Arrangement has a unique ID. Every Arrangement has its own lifecycle. Things happen to Arrangements through Activities.

Activity

An Activity is something that happens to an Arrangement. A drawdown is an Activity. A repayment is an Activity. An interest accrual during COB is an Activity. A rate amendment is an Activity. A closure is an Activity.

Each Activity triggers a set of Actions — the actual work: generating accounting entries, updating balances, recalculating schedules, sending notifications.

This is the level where most production support work happens. When something goes wrong with a customer's loan, you are almost always looking at an Activity that failed, produced the wrong output, or triggered at the wrong time.

The hierarchy in plain terms

Put it all together and it looks like this:

Product Family
  └── Product
        ├── Property Class → Property → Product Condition
        ├── Property Class → Property → Product Condition
        └── Property Class → Property → Product Condition
                                              ↓
                                        Arrangement
                                              ├── Arrangement Condition (negotiated values)
                                              └── Activities (things that happen over time)

A useful analogy: a Product is a recipe. The Property Classes are the categories of ingredient (dairy, protein, vegetable). The Properties are specific ingredients (mature cheddar, free-range chicken, vine tomatoes). The Product Conditions are the default quantities. The Arrangement is the actual meal you cooked for a specific customer — which might have had the cheese substituted because they were lactose intolerant.

Activities are what happens after the meal is served. The customer pays. The bill is adjusted. They come back for dessert. Eventually the table is cleared and the arrangement is closed.

The Design, Proof, Publish lifecycle

One of the things that confuses people new to AA is that you can change a product definition and nothing seems to happen.

That is because product changes in AA go through a three-stage lifecycle:

Design — you are editing. The changes exist only in the design version. Nothing live is affected.

Proof — the system validates the product definition, checks for consistency, and compiles the product catalogue. Errors surface here. This is also when the inheritance chain is resolved — all the values from parent families are merged with the child product's configuration.

Publish — the product catalogue is pushed to the live environment. Only at this point do changes take effect for new Arrangements. Existing Arrangements are not automatically updated — that requires a separate process.

This lifecycle exists for good reasons. Publishing a broken product definition to production is significantly worse than having a temporary freeze on changes. That said, it does mean that fixing a typo in a product requires a Proof and Publish cycle, which at some banks involves a change request, a sign-off meeting, and a two-week queue.

It is what it is.

Why this matters in production

Understanding AA at this level makes a practical difference to what you can do in support.

When a customer arrangement has the wrong interest rate, you now know to check whether the issue is in the Product Condition (affecting all arrangements on that product) or in the Arrangement Condition (affecting only that customer). The former is a configuration problem. The latter might be a booking error.

When an Activity fails during COB, you now know that Activities have a chain of Actions underneath them, and the failure is usually in one specific Action — not the whole Activity. Finding which Action failed and why is much faster once you understand the structure.

When someone says “we need a new product”, you now know that in AA this means defining Property Classes, building Properties, setting Product Conditions, and going through Proof and Publish. It is not a five-minute job, but it is also not writing new code.

When the inheritance chain is wrong — meaning a product is picking up a value from a parent family that should have been overridden — you now know where to look. Check each level of the hierarchy in turn until you find where the value is actually coming from.

What comes next

This article has covered the skeleton of AA: what it is, why it exists, and what its core concepts mean.

The interesting parts — how interest property classes actually work, how COB processes arrangements, what goes wrong with reverse-replay, how to diagnose a failed activity, what scope actually means in practice — are each worth their own article. This is the foundation. Everything else builds on it.

If one thing sticks, let it be this: AA is configuration, not code. Almost everything that appears to be a bug in AA is actually a misconfiguration somewhere in the product hierarchy. That reframing changes how you approach every support call. You are not looking for broken code. You are looking for the point in the hierarchy where the expected value stopped being the actual value.

Find that, and you have found the problem.