How to test building society member account integrations

Building society member account integration testing checks that account, membership and transaction data move accurately between a building society's systems, and that each system applies the same agreed business rules. It covers interfaces such as a member portal, core banking platform, membership register, payments service and statement or notification service, including how errors and retries affect account state.

What building society member account integration testing covers

A member account journey can cross several services. For example, an application may create a customer record, open a savings account in the core system, record membership status, accept a deposit through a payment service and display the resulting balance in a digital channel. Integration testing verifies the hand-offs and the resulting state in each relevant system.

First establish the product and membership rules for the journey. A savings account, a member record and a shareholding or qualifying product may be represented separately. The precise relationship depends on the society's product design and rules. Identify which system owns each data item, which identifier links the records and what constitutes a successful update. Do not assume that an account number is also the member identifier.

Check interface contracts and mappings, including required fields, formats, status codes, event types and version compatibility. Agree how the systems handle effective dates, monetary precision, customer or member identifiers and optional fields. Where the integration uses messages or scheduled files rather than synchronous APIs, include timing, ordering, acknowledgements and reconciliation in the test scope.

Prepare test data and environments

Create controlled test records for the relevant account and membership states: an eligible applicant, an existing member opening another product, an ineligible application, a joint account where applicable, and an account that is restricted or closed. Confirm expected links between customer, member and account records before execution. Use approved synthetic or appropriately masked data, and keep test records isolated from production.

Check that dependent services are available in the test environment, or use agreed service simulations when they are not. Record environment and configuration versions. Differences in product rules, reference data, interest settings or interface versions can cause false failures or conceal defects. Ensure test accounts can be reset or that each run uses unique data so that retries do not contaminate later results.

Design tests around the data flow

For each journey, verify both the response to the initiating system and the persisted result downstream. Useful checks include:

• Account creation uses the correct member and product identifiers, with the expected status and opening date.
• A deposit or withdrawal updates the ledger and the balance shown to the member, according to the defined processing model.
• A membership or account status change reaches dependent services and is reflected in subsequent enquiries.
• Invalid, incomplete or mismatched identifiers produce the specified rejection or review outcome without creating partial records.
• Repeated delivery of the same request or message does not create a duplicate account or transaction where the interface is designed to be idempotent.
• A downstream timeout, unavailable service or rejected message can be recovered and reconciled without losing or duplicating a posting.

Use API assertions, database or ledger checks, message inspection and user-interface checks as appropriate. A successful HTTP response alone does not prove that the account was created correctly or that a transaction reached the ledger. Compare identifiers, status, amount, currency and relevant dates across systems, while respecting access controls for sensitive data.

Worked example: opening a member savings account

Suppose an eligible applicant opens a savings account through a member portal. The portal sends an application to the account service, which creates an account and returns an account identifier. A membership service records the applicable membership relationship, and the portal displays the account.

For the positive test, submit an eligible application with a known test customer. Assert that the account service returns the expected result, the account exists once with the correct product and status, the membership record links to the correct customer and account where required, and the portal displays the returned account identifier. Then repeat the request using the same idempotency key if the contract supports one. Verify that the retry does not create a second account.

For a failure test, make the membership dependency reject the request or time out. Check the specified outcome: the account creation may be rejected, held for recovery or completed with a pending status, depending on the design. Verify that retries follow the contract and that reconciliation can identify any incomplete relationship. The expected behaviour must come from approved requirements, not assumptions made by the test.

Diagnose failures and verify completion

A mismatch can arise from a mapping defect, stale reference data, delayed message processing, an incorrect rule, a duplicate retry or environment drift. Capture correlation identifiers, timestamps, request or message references, and relevant before-and-after states. This evidence helps distinguish a genuine integration defect from a delayed process or test setup problem.

Define completion criteria for each journey: expected records and statuses exist, balances and transaction details reconcile, rejected work has no unintended side effects, and recoverable failures reach the agreed final state. Link cases to requirements and retain sanitised evidence for review. For broader journeys across channels and back-office systems, see Cross-system testing in banking; for shared account and ledger behaviours, see Core banking integration testing.