Skip to main content

Other payment related functionalities

There are many other functionalities in a bank that are related to payments. It is important to be aware of them, and if changes in the system apply to them, to test them.

These are general functionalities and their logic can differ by bank. Information should be gathered from Business Analysts to understand the exact logic expected in each bank.

Account Status​

Payment accounts in the bank can have different statuses, for example:

  • Open - account is open as usual
  • Closed - account is closed and most likely can’t accept any incoming or outgoing payments
  • Blocked for Debit - account cannot create any outgoing payments
  • Blocked for Credit - account cannot accept any incoming payments
  • Dormant/Inactive - account has not been used for X days (restrictions depend on bank)

Account Type​

Accounts can have different types:

  • Private / Corporate accounts - based on whether the user is a private person or a company
  • Card accounts (account with a card attached)
  • Pension / Salary account
  • EUR/USD/GBP/etc account
  • Interest account
  • Savings account
  • Etc.

All account types can have different restrictions or logic. Only certain types of payments may be allowed, allowed amounts may differ, only certain currencies could be used, and payment details may vary (IDs, addresses, etc).

Account Balance​

The account balance is the amount of money the customer has available to create payments.

  • Main balance is usually kept in the core banking system
  • Side systems like Internet Bank usually retrieve this info from the core system
  • Other systems may use the same logic, so it’s important to test how balances are reflected across systems

Customer Statements​

A customer statement lists payments including all details like amount, currency, references, etc.

  • Can be generated in many formats:
    • UI
    • XML (CAMT, FIDAVISTA format)
    • PDF
    • CSV
  • Can be created by customer (Internet Bank) or bank employees (internal or for customer)
  • Can include:
    • Intra-day statements (e.g., CAMT.052)
    • End-of-day statements (e.g., CAMT.053)

Testing suggestions:

  • Check statements for different payment types, directions, currencies, and payment reversals

Fraud / Money Laundering Screening​

  • Prevent illegal, unauthorized, or fraudulent payments
  • Payment details are checked against rules (receiver name, account, country, etc)
  • Payments that fail rules may be held for review by a human employee

Testing suggestion:

  • Include cases with different payment types and directions

Local/Special Characters​

  • Check how multiple systems handle local/special characters
  • Rules can differ by country, bank, or payment system (e.g., UTF-8 subset)
  • Test both sending and receiving characters across all systems (core banking, Internet Bank, employee interface)

Pay attention to file encoding (e.g., UTF-8) to avoid message corruption

Time Zones​

  • SEPA/Instant messages include year, date, time, and time zone
  • Servers outside bank’s time zone can cause issues (display or processing errors)
  • Test payments around midnight and daylight savings changes

Holidays / Weekends​

  • Logic differs by payment type:
    • Instant payments: usually 24/7
    • SEPA payments: workdays only
  • Test that payments are processed (or not) correctly during weekends and holidays

Message Field Limits​

  • Fields may have different allowed lengths in UI, core systems, and outgoing messages
  • Special characters may occupy more than one character in storage
  • Test max/min character lengths and ensure no truncation occurs

Payment Templates​

  • Customers can create templates for recurring payments
  • Changes in system can break old templates
  • Test both old and new templates, including “copy payment” functionality

Reference Data​

  • Reference data defines bank names, BIC codes, SEPA/Instant directories, etc.
  • Files can arrive daily, monthly, or manually
  • Testing areas:
    • Correct storage of reference data
    • Correct use in payments (e.g., ENABLED/DISABLED banks)

Reconciliation​

  • Compare payments in banking system vs external payment systems
  • Identify discrepancies: lost messages, technical issues, incorrect identifiers
  • Test matching for outgoing and incoming payments, including returns

End of Day Process​

  • Processes run at day’s end (sending statements, updating internal dates, etc.)
  • Can vary in duration (minutes to hours)
  • Test payments during End of Day, especially 24/7 Instant payments

Rules and Regulations​

  • Banks must comply with legal and interbank rules
  • Examples:
    • Mandatory Instant payments (EU 2024)
    • SEPA rules post-Brexit (UK)
    • Mandatory inclusion of sender address for some countries
    • Customer data privacy rules

Loans and Credit Lines​

  • Borrowed funds can be separate accounts or credit lines
  • Test that payments respect available balance + credit limits
  • Prevent exceeding credit limits

Customer Data Systems​

  • Auto-populated fields: name, address, identification codes
  • Stored in core banking system; may be edited/viewed elsewhere
  • Test changes if payment system edits or populates these fields

Fees​

  • Banks charge fees for:
    • Payments (type, urgency, special packages)
    • Monthly/Yearly fees (accounts, credit cards)
    • Other services
  • Some fees taken from separate charge accounts
  • Test that fees are correctly applied according to rules