What is Avaloq banking application testing?

Avaloq banking application testing is the verification of an Avaloq-based banking system and its configured workflows, interfaces and data against business, operational and control requirements. It checks that transactions produce the expected customer outcomes and accounting effects across the bank's implementation, including connected applications and services where they form part of the workflow.

What Avaloq banking application testing covers

The scope depends on how the bank has configured and integrated its Avaloq environment. Testing may cover customer and account records, product rules, transaction processing, fees and interest, payment handling, accounting entries, user permissions and operational processes. It can also include channels and external services that exchange data with the application.

A test should trace a business requirement through the relevant screens, services, configuration and downstream processing. For a transfer, that may mean checking input validation, approval rules, posting to the relevant accounts, payment status, and any resulting ledger or customer-facing records. The exact expected result depends on the bank's product setup, accounting rules and integration design.

Testing should include valid transactions and cases such as insufficient funds, invalid account details, duplicate requests, rejected approvals and failed downstream responses. These cases can reveal defects in validation, status handling, access controls or recovery behaviour. If a process includes overnight or scheduled work, test its timing, restart behaviour and resulting balances as well.

How to plan and verify the tests

Start with the implementation's requirements, configuration and interface contracts. Confirm which version and environment are under test, which product and customer data apply, and what each connected system is expected to do. Configuration differences between environments can change a result, so record relevant settings and dependencies alongside test evidence.

Prepare controlled test data for the required account states, permissions, balances and transaction histories. Protect sensitive information, and check that test records remain consistent across systems. Where a test relies on an external service, agree whether it will use a test endpoint, a simulator or a controlled integration environment. A simulated response can verify handling of a known condition, while an end-to-end run is needed to check the real interface and shared data flow.

Use functional tests for individual rules and workflows, integration tests for data exchanged between Avaloq and connected systems, and end-to-end tests for complete business journeys. Regression testing is important after configuration, interface or release changes because an adjustment to one process can affect related products or accounting outcomes. Automation can repeat stable checks, while exploratory testing can investigate unfamiliar behaviour and operational edge cases.

A passing screen message alone is weak evidence for a financial transaction. Verify the resulting transaction state and, where relevant, account balances, postings, downstream messages and audit records. Reconcile expected and actual results using the bank's approved sources of truth. When a test fails, distinguish an application defect from a data issue, environment drift, an unavailable dependency or an incorrect expectation before assigning the cause.

Practical example: testing a customer transfer

Assume the bank's configured rules allow a customer to transfer funds between two eligible accounts. Create test accounts with known opening balances, confirm the user has the required access, and record the expected transfer amount, fees and posting rules. Submit a valid transfer, then check that the application records the correct status, the debit and credit amounts are correct, and any required downstream payment or accounting records appear.

Repeat with an amount above the available balance and with a duplicate submission. The first case should follow the configured rejection or overdraft rules; the second should follow the implementation's duplicate-handling rules. Verify the resulting records rather than relying solely on the interface response. The test is complete when the observed outcome matches the approved requirement and the relevant systems agree.