AA Property Classes in Practice

If you have read the AA introduction, you know the building blocks: Product Families, Property Classes, Properties, Product Conditions, Arrangements, and Activities. If you have read the Interest article, you know how the Interest Property Class works — the accrual, the payment schedule, the difference between billing and capitalising. Both of those articles are assumed knowledge for what follows.

This article covers the Property Classes that are not Interest — specifically the ones that cause the most production incidents, the most configuration regret, and the most “why is the accounting wrong” support calls. Interest gets the attention because interest is visible to customers. The other Property Classes get the attention because they determine whether the product actually functions as a financial instrument, which is arguably more important but considerably less visible until something breaks.

The Property Classes that matter

AA has dozens of Property Classes. Most products use somewhere between four and eight. The ones that cause the most problems in production are not the obscure ones — they are the common ones that everyone assumes are straightforward, configures quickly, and does not verify until a customer or an auditor notices the output is wrong.

Account

The Account Property Class controls the creation and management of the underlying T24 account record that sits beneath every AA arrangement. Every arrangement has an account. The Account Property Class decides what type of account it is, what currency it operates in, and how it behaves at the core banking level.

This sounds administrative. It is not. The Account Property Class is the bridge between AA and the core banking system, and getting it wrong means the arrangement exists in AA but the account in the core system is either missing, misconfigured, or operating under rules that conflict with what the AA product definition says.

What it controls

• The account category — which determines the core system behaviour (current account, savings account, loan account)
• The currency of the underlying account
• The account title and customer linkage
• The account officer and relationship manager assignments
• Whether the account allows overdraft or not, and under what conditions

What goes wrong

The account category is set to a value that does not match the product's intended behaviour. A mortgage product linked to a current account category will function — the system will not stop you — but the core banking treatment of that account will be wrong. Interest calculation, regulatory reporting, statement generation. None of it breaks visibly. It just produces output that is wrong in ways that are discovered during an audit.

The currency is set to a default that does not match the customer's negotiation. This happens when the product condition locks the currency and the customer wanted a different currency. The arrangement cannot override it because scope prevents it. The fix is a product change, which requires Proof and Publish, which at some banks requires a change request and a meeting.

The diagnostic sign of an Account Property Class problem is an arrangement that exists and appears healthy in AA but produces unexpected behaviour at the core system level. The customer's statement does not match the product definition. The regulatory classification is wrong. The interest posting goes to a suspense account. These are all account-level issues, not product-level issues, and the Account Property Class is where they live.

Charges

The Charges Property Class controls fees. Arrangement fees, maintenance fees, early redemption penalties, late payment fees, statement fees, cheque book fees — every charge a product can apply is configured through a Charges Property.

A single product can have multiple Charge Properties — an arrangement fee charged at booking, a monthly maintenance fee, a penalty fee for missed payments, an early settlement fee. Each one is a separate Property with its own calculation method, its own billing frequency, its own trigger conditions. They are independent, which means getting three right and one wrong is entirely possible and surprisingly common.

What it controls

• The charge amount — flat fee or percentage of a balance
• The charge calculation method — fixed, tiered, or rate-based
• The charge trigger — at booking, monthly, on event, on closure
• The charge billing — added to the balance, billed separately, or capitalised
• Waiver rules — under what conditions the charge is not applied

What goes wrong

The waiver condition is wrong. Charges have waiver rules — if the customer meets certain conditions, the charge is not applied. A common configuration error is setting the waiver condition too broadly, meaning charges that should apply do not, or too narrowly, meaning charges apply to customers who were meant to be exempt. The first error loses the bank money silently. The second generates customer complaints, which is at least visible.

The charge is calculated on the wrong basis. A maintenance fee that should be a flat £10 per month is configured as a percentage of the outstanding balance. For a mortgage, this produces a maintenance fee that starts high and gradually declines, which is not what anyone intended and will eventually be noticed by someone comparing statements across two different months.

The charge trigger fires at the wrong time. A setup fee configured to fire monthly instead of at booking. Every month the customer is charged the setup fee again. This is discovered quickly, usually because the customer notices their balance is increasing in a direction they were not expecting, but the fix requires correcting the configuration and then reversing the incorrectly applied charges, which is a manual process that someone has to do.

The diagnostic approach for charge problems: identify which Charge Property is producing the wrong output, check the calculation method, check the trigger condition, check the waiver rules. The answer is almost always in one of those three settings. The rate is rarely the problem. The method or the trigger is.

Accounting

The Accounting Property Class controls how accounting entries are generated for arrangement events. Every drawdown, every repayment, every interest accrual, every charge billing — each of these produces accounting entries, and the Accounting Property Class defines where those entries go.

This Property Class is the one that separates a product that works correctly in customer-facing terms from a product that is actually correct as a financial instrument. The customer sees the right balance. The general ledger sees the right entries. These are different things, and they can be different in ways that are invisible until month-end reconciliation produces an unreconciled difference that someone has to explain.

What it controls

• The chart of accounts mapping — which GL accounts receive which entries
• The debit and credit rules for each event type
• The accounting treatment of accruals vs actuals
• Multi-currency accounting behaviour
• Profit and loss vs balance sheet classification

What goes wrong

The GL mapping is wrong. Interest income posts to the wrong GL account. The customer sees the right interest. The bank's financial statements post interest income to a suspense account. This is discovered at month-end by the finance team, who are not happy about it. The fix is straightforward — correct the accounting mapping — but the entries that have already been posted need to be reversed and rebooked, and the finance team has opinions about journal reversals that were not caused by them.

The accrual treatment is inconsistent. Some events post on an accrual basis, some on a cash basis, and the product was designed assuming consistent treatment. The result is that the P&L shows revenue that does not match the cash flow, and the difference accumulates over time until someone investigates.

Multi-currency accounting is wrong. The product allows multi-currency arrangements but the accounting Property Class uses a single-currency mapping. Foreign currency entries post to the domestic currency GL accounts. The resulting revaluation differences are someone else's problem until they become everyone's problem.

Accounting Property Class problems are the least visible to customers and the most visible to auditors. The diagnostic approach is to trace a single transaction through from the arrangement event to the GL posting and verify that every entry landed in the right place. This takes longer than most other Property Class diagnostics, which is why accounting problems tend to persist until someone specifically looks for them.

Balances

The Balances Property Class controls how the arrangement tracks money. Not how it accrues interest. Not how it posts accounting entries. What the arrangement itself considers to be its principal balance, its accrued interest balance, its fee balance, its penalty balance — every number the customer sees on a statement that is not an interest rate.

What it controls

• The principal balance — the outstanding amount
• The accrued interest balance — interest earned but not yet billed
• The fee balance — charges applied but not yet paid
• The penalty balance — penalty interest or fees outstanding
• Balance updates — how and when balances are incremented or decremented

What goes wrong

The principal balance includes accrued interest. This is the most common balance problem. The configuration has been set to add accrued interest to the principal balance before the interest has been capitalised. The customer sees a balance that is higher than expected, and the difference is accrued interest that should be tracked separately. The support call: “my mortgage balance is wrong.” The answer: check whether the balance property is including accrued interest.

A balance type is missing. The product definition omits a balance type that a downstream report or interface expects. The balance enquiry returns null. The report fails. The interface rejects the arrangement. Adding the missing balance type is simple but the existing arrangements need to have the balance populated retrospectively, which may require a COB run or a manual reconciliation.

Balance updates are not firing. The balance shows a value that is weeks out of date. The update trigger — an activity, a COB process, an event — is either not configured or not executing. The balance enquiry returns a number that looks plausible but is wrong. This is particularly dangerous because nobody checks the balance enquiry against the actual transaction history unless something prompts them to. The customer might be making repayments that are reflected in the transaction history but not in the balance totals.

Settlement

The Settlement Property Class controls how money moves. When a drawdown happens, the Settlement Property decides where the funds go — which account, through which payment method, with what timing. When a repayment happens, the Settlement Property decides how the money is collected and where it is credited.

What it controls

• The disbursement method — internal transfer, external payment, cheque
• The settlement account — where money comes from and goes to
• The settlement timing — immediate, end of day, or scheduled
• The settlement instructions — payment details for external transfers

What goes wrong

The settlement account is wrong. A loan disbursement credits the wrong customer account. This is discovered quickly because someone receives money they were not expecting and someone else does not receive money they were expecting, and both parties contact the bank. The fix is urgent. The root cause is usually a settlement instruction that references a default account rather than the arrangement-specific account, or a settlement account that was configured at the product level when it should have been configured at the arrangement level.

The settlement method does not match the payment type.An arrangement configured to settle via internal transfer when the beneficiary requires an external payment. The disbursement instructions are generated but the receiving system rejects them. The arrangement shows the disbursement as pending while the money sits in a holding account and nobody notices because pending disbursements do not trigger alerts.

Settlement problems are the highest-urgency Property Class problems because they involve actual money moving to the wrong place. The diagnostic sequence: check the settlement account, check the settlement method, check whether the settlement instruction was generated correctly, check whether the receiving system acknowledged it. One of these will contain the answer.

Payment Schedule

The Payment Schedule Property Class was covered in the Interest article, but it deserves a specific mention here because its reach extends beyond interest. The Payment Schedule controls when and how any amount is made due — interest, principal, charges, fees — and getting the method wrong for non-interest amounts is a common source of configuration problems.

The Payment Schedule Method attribute — DUE, CAPITALISE, PAY, MAINTAIN — applies to every amount type linked to that schedule. If a product has a single Payment Schedule Property that covers both interest and charges, changing the method to CAPITALISE will capitalise both. If the charges should be billed separately, they need their own Payment Schedule Property with a method of DUE.

The diagnostic sign of a Payment Schedule problem that is not interest-related: charges that appear on the balance but are never billed, principal repayments that are scheduled but never collected, fees that accrue but are never made due. The Payment Schedule tells the system when to act. If it is not acting, the schedule is the first thing to check.

Limit

The Limit Property Class controls the credit limits applied to an arrangement. For lending products, this is the maximum amount that can be drawn. For overdraft products, this is the overdraft limit. For credit cards — if you are unfortunate enough to be dealing with AA credit card products — this is the spending limit.

What goes wrong

The limit is configured at the product level and cannot be overridden. Every customer gets the same limit regardless of their credit assessment. The product condition scope has locked the limit field, and the arrangement-level negotiation is ignored. The fix is a product change, and the bank has been booking arrangements for six months without realising the negotiated limit was not being applied.

The limit is not reducing as the customer draws down.The limit is defined but the utilisation tracking is not configured correctly. The customer can draw repeatedly without the system recognising that the available limit is being consumed. This is discovered when the outstanding balance exceeds the limit, which triggers an exception report. Someone in credit risk has a strong opinion about this.

Limit problems are high-consequence and low-frequency. When they occur, they involve real exposure and real regulatory implications. The diagnostic check: verify that the limit is being applied at arrangement level, verify that utilisation is tracking correctly, and verify that the limit type matches the product's intended credit structure.

The Property Class dependency map

One of the things that makes AA configuration difficult is that Property Classes depend on each other. A product with an Interest Property Class but no Accounting Property Class will accrue interest without posting accounting entries. A product with an Accounting Property Class but no Balances Property Class will generate accounting entries for balances that the arrangement does not track. The dependencies are not enforced by the system. The system will let you create a product that is missing a required Property Class, and it will not tell you until the output is wrong.

The minimum viable Property Class set for a lending product:

• Account — the core banking account
• Interest — the interest calculation
• Payment Schedule — when amounts are due
• Balances — tracking what is owed
• Accounting — posting to the general ledger
• Settlement — moving the money
• Limit — controlling the exposure

For a deposit product, swap Limit for Charges and add a different Settlement configuration. The principle is the same: every Property Class has a purpose, and missing one means the product is incomplete in a way that will eventually surface.

The diagnostic implication: when investigating a product that is producing wrong output, check whether all the required Property Classes are present before investigating the configuration of individual Properties. A missing Property Class is harder to spot than a misconfigured one because the system does not flag the absence.

The cross-Property-Class problems

The most difficult AA configuration problems are the ones that span multiple Property Classes. These are not configuration errors in a single Property. They are inconsistencies between Properties that are individually correct but collectively wrong.

Interest says capitalise. Settlement says bill. The Interest Property is configured to capitalise accrued interest — add it to the principal. The Settlement Property is configured to bill the customer for the interest amount. Both are correct in isolation. Together they produce a situation where the interest is capitalised (the principal increases) and also billed (the customer is asked to pay an amount that has already been added to the loan). The customer pays twice for the same interest, once through a larger loan and once through a payment demand.

Charges fire monthly. Accounting only recognises quarterly.The Charges Property applies a monthly fee. The Accounting Property posts charge-related entries quarterly. For two months out of three, the charge is applied to the customer's balance but no accounting entry is generated. The customer sees the charge. The general ledger does not. Month-end reconciliation produces a difference.

Balances include accrued interest. Interest capitalises quarterly.The customer sees a balance that includes accrued interest. Every quarter the interest is capitalised, which increases the principal balance and resets the accrued interest to zero. The customer sees their balance jump up (capitalisation adds to principal) and then drop (accrued interest resets). The net effect is correct but the visual effect is alarming, and alarmed customers call the bank.

Cross-Property-Class problems are diagnosed by tracing a single event — a drawdown, a repayment, a COB accrual — through every Property Class that touches it, and verifying that the outputs are consistent. This is the most time-consuming category of AA diagnosis and the one that most benefits from having done it before.

The practical checklist

When investigating an AA product that is producing wrong results, work through this before assuming the code is broken:

1. Are all required Property Classes present? Missing one is silent and destructive.
2. Is the scope correct on each Property? Check whether the arrangement can override product defaults where it needs to.
3. Are the Property Classes consistent with each other? Interest capitalise vs Settlement bill, Charges frequency vs Accounting frequency.
4. Trace a single event through every Property Class. The drawdown. The first repayment. The first COB accrual. Verify each output.
5. Check the inheritance chain. A value from a parent Product Family may be overriding a value you set at the product level without you realising.
6. Verify in a non-production environment before publishing. The Design-Proof-Publish lifecycle exists for a reason, and that reason is to prevent a misconfigured product from reaching production. Use it.