Chapter 34: Banking and Payment Systems in COBOL

Opening Vignette: The Midnight Batch

It is 12:01 a.m. on a Thursday morning. Across the data centers of America's largest banks, the nightly batch cycle has begun. In the next five hours, COBOL programs will process over 400 million transactions: deposits that arrived at teller windows, withdrawals from ATMs in thirty countries, wire transfers between multinational corporations, ACH payroll files containing the salaries of millions of workers, credit card authorizations that accumulated throughout the day, and interest accruals on every savings account and certificate of deposit the bank holds.

There is no margin for error. A rounding mistake on interest calculations could trigger regulatory penalties. A misposted debit could overdraw thousands of accounts. A malformed ACH file could delay payroll for an entire Fortune 500 company. And yet, night after night, these COBOL programs execute with extraordinary precision, moving trillions of dollars through the global financial system while most of the world sleeps.

Banking is the domain for which COBOL was born. The language's decimal arithmetic eliminates the floating-point rounding errors that plague other languages when handling currency. Its file processing capabilities were designed for exactly the kind of high-volume sequential processing that banking demands. Its verbose, English-like syntax makes programs readable by the auditors and regulators who scrutinize every line of financial code. And its backward compatibility means that business rules encoded in COBOL programs twenty or thirty years ago still execute correctly today, a critical property in an industry where regulatory compliance spans decades.

In this chapter, you will learn how COBOL programs power the core operations of modern banking: account management, transaction posting, payment processing, check digit validation, ACH file handling, wire transfers, and statement generation. You will also learn about the regulatory frameworks that shape how banking software is designed and the batch processing patterns that orchestrate the nightly cycle. By the end of this chapter, you will understand why COBOL remains the foundation of global banking and how to write the programs that keep it running.

34.1 Banking Systems Overview

The Scope of Banking Technology

A modern bank's technology infrastructure is vast, encompassing hundreds of interconnected systems. At the heart of this infrastructure sits the core banking system -- the software that manages customer accounts, processes transactions, and maintains the authoritative record of every dollar the bank holds. The core banking system is the system of record: when any other system needs to know a customer's balance, account status, or transaction history, it queries the core.

Most core banking systems in the United States were built in COBOL and continue to run on IBM mainframes. According to industry surveys, COBOL processes approximately 95 percent of ATM transactions, 80 percent of in-person banking transactions, and the vast majority of overnight batch processing at large and mid-sized banks. The Federal Reserve's own payment processing systems rely on COBOL programs that have been refined over decades.

Core Banking Components

A core banking system consists of several major subsystems:

Customer Information File (CIF): The CIF is the master database of customer information. It stores names, addresses, Social Security numbers, tax identification numbers, contact information, and relationship data. A single customer may have multiple accounts -- a checking account, a savings account, a home mortgage, and a credit card -- but appears only once in the CIF. The CIF links all of a customer's accounts together, enabling a unified view of the relationship.

Account Master File: The account master file contains one record for each account in the bank. Each record stores the account number, account type, current balance, available balance, interest rate, account status, and dozens of other attributes. In a VSAM-based system, this is typically a Key-Sequenced Data Set (KSDS) with the account number as the primary key.

Transaction Processing Engine: This subsystem handles the posting of transactions to accounts. It validates each transaction against business rules (sufficient funds, account status, daily limits), updates account balances, and writes transaction history records. Transaction processing may occur in real time (for ATM withdrawals and point-of-sale purchases) or in batch (for ACH payments, interest accrual, and fee assessment).

General Ledger Interface: Every transaction that affects an account must also be reflected in the bank's general ledger. The GL interface generates the debit and credit entries that keep the bank's books in balance. Double-entry bookkeeping is fundamental: for every dollar debited from one account, a dollar must be credited to another.

Payment Processing Systems: These systems handle the various payment channels through which money moves: ACH (Automated Clearing House), wire transfers (Fedwire and SWIFT), check clearing, card processing, and real-time payments. Each channel has its own message formats, processing rules, and settlement procedures.

Regulatory Reporting Systems: Banks are among the most heavily regulated businesses in the world. Regulatory reporting systems generate the filings required by federal and state regulators, including Currency Transaction Reports (CTRs), Suspicious Activity Reports (SARs), call reports, and stress test submissions.

The Transaction Processing Lifecycle

Every financial transaction, whether initiated at a teller window, an ATM, a mobile phone, or through an electronic payment network, follows a common lifecycle:

1. Origination: The transaction is initiated by a customer, a bank employee, or an automated process.
2. Authorization: The system validates the transaction. Does the account exist? Is it active? Does it have sufficient funds? Is the transaction within daily limits? Does it trigger any fraud alerts?
3. Memo Posting: The transaction is recorded as pending. The available balance is adjusted, but the ledger balance is not yet affected. This is sometimes called a "hold" or "pre-authorization."
4. Final Posting: During the nightly batch cycle (or in real time for certain transaction types), the transaction is posted to the account master file. The ledger balance is updated, and a permanent transaction history record is created.
5. Settlement: For transactions involving other financial institutions (ACH payments, wire transfers, card transactions), funds are settled through clearing networks. Settlement may occur on the same day, the next business day, or on a specified settlement date.
6. Reconciliation: Control totals are balanced, exception reports are generated, and audit trails are verified to ensure that every transaction has been properly recorded.

34.2 Account Master File Design

The account master file is the most critical data structure in a banking system. Its design must accommodate dozens of account types, hundreds of attributes, and billions of transactions over the life of an account. In a COBOL/VSAM environment, the account master is typically implemented as a KSDS file with the account number as the primary key and one or more alternate indexes for customer ID, Social Security number, and tax identification number.

Account Types

A typical bank supports the following account types:

Account Record Layout

The following COBOL record layout represents a typical account master record. In production systems, this layout would be defined in a copybook that is shared across all programs that access the account master file.

       01  ACCT-MASTER-RECORD.
           05  ACCT-KEY-AREA.
               10  ACCT-NUMBER            PIC X(12).
           05  ACCT-CUSTOMER-INFO.
               10  ACCT-CIF-NUMBER        PIC X(10).
               10  ACCT-TAX-ID            PIC X(09).
               10  ACCT-NAME-LAST         PIC X(25).
               10  ACCT-NAME-FIRST        PIC X(20).
               10  ACCT-NAME-MIDDLE       PIC X(01).
           05  ACCT-TYPE-INFO.
               10  ACCT-TYPE-CODE         PIC X(03).
                   88  ACCT-CHECKING      VALUE 'CHK'.
                   88  ACCT-SAVINGS       VALUE 'SAV'.
                   88  ACCT-MONEY-MARKET  VALUE 'MMA'.
                   88  ACCT-CD            VALUE 'CD '.
                   88  ACCT-LOAN          VALUE 'LON'.
                   88  ACCT-MORTGAGE      VALUE 'MTG'.
               10  ACCT-SUB-TYPE          PIC X(02).
           05  ACCT-STATUS-INFO.
               10  ACCT-STATUS-CODE       PIC X(01).
                   88  ACCT-ACTIVE        VALUE 'A'.
                   88  ACCT-CLOSED        VALUE 'C'.
                   88  ACCT-FROZEN        VALUE 'F'.
                   88  ACCT-DORMANT       VALUE 'D'.
               10  ACCT-OPEN-DATE         PIC 9(08).
               10  ACCT-CLOSE-DATE        PIC 9(08).
               10  ACCT-LAST-ACTIVITY     PIC 9(08).
           05  ACCT-BALANCE-INFO.
               10  ACCT-LEDGER-BAL        PIC S9(11)V99
                                          USAGE COMP-3.
               10  ACCT-AVAIL-BAL         PIC S9(11)V99
                                          USAGE COMP-3.
               10  ACCT-HOLD-AMT          PIC S9(11)V99
                                          USAGE COMP-3.
               10  ACCT-PENDING-CR        PIC S9(11)V99
                                          USAGE COMP-3.
               10  ACCT-PENDING-DR        PIC S9(11)V99
                                          USAGE COMP-3.
           05  ACCT-INTEREST-INFO.
               10  ACCT-INT-RATE          PIC 9V9(06).
               10  ACCT-INT-ACCRUED       PIC S9(09)V99
                                          USAGE COMP-3.
               10  ACCT-INT-PAID-YTD      PIC S9(09)V99
                                          USAGE COMP-3.
               10  ACCT-INT-FREQ          PIC X(01).
                   88  ACCT-INT-DAILY     VALUE 'D'.
                   88  ACCT-INT-MONTHLY   VALUE 'M'.
                   88  ACCT-INT-QUARTERLY VALUE 'Q'.
           05  ACCT-LIMITS.
               10  ACCT-DAILY-W-LIMIT     PIC S9(07)V99
                                          USAGE COMP-3.
               10  ACCT-DAILY-W-USED      PIC S9(07)V99
                                          USAGE COMP-3.
               10  ACCT-OD-LIMIT          PIC S9(07)V99
                                          USAGE COMP-3.
           05  ACCT-FILLER                PIC X(50).

Several design decisions in this layout deserve explanation:

COMP-3 (Packed Decimal) for monetary fields: All balance and amount fields use USAGE COMP-3, which stores two digits per byte plus a sign nibble. This is the standard representation for financial data on IBM mainframes. It provides exact decimal arithmetic and is more space-efficient than display numeric (one digit per byte). A field of PIC S9(11)V99 COMP-3 stores amounts up to $99,999,999,999.99 in only 7 bytes.

Separate ledger and available balances: The ledger balance is the official, posted balance of the account. The available balance reflects the ledger balance minus holds plus pending credits. These two balances often differ: a check deposit may increase the available balance by $200 immediately (the first $200 made available under Regulation CC) while the full check amount posts to the ledger balance only after the check clears.

Status codes with condition names: The 88-level condition names make the program logic self-documenting. A paragraph that reads IF ACCT-FROZEN is immediately understandable, even to someone unfamiliar with the system.

Filler space: The 50-byte filler at the end of the record provides room for future expansion without requiring the entire VSAM file to be unloaded and reloaded. This is a standard practice in banking systems where record layouts must remain stable for years.

Transaction Record Layout

Transactions are the lifeblood of a banking system. Every financial event is recorded as a transaction record, which serves both as the mechanism for updating account balances and as the permanent audit trail of all account activity.

       01  TRAN-RECORD.
           05  TRAN-KEY-AREA.
               10  TRAN-ACCT-NUMBER       PIC X(12).
               10  TRAN-SEQUENCE          PIC 9(06).
           05  TRAN-TYPE-INFO.
               10  TRAN-TYPE-CODE         PIC X(03).
                   88  TRAN-DEPOSIT       VALUE 'DEP'.
                   88  TRAN-WITHDRAWAL    VALUE 'WDR'.
                   88  TRAN-TRANSFER-IN   VALUE 'TRI'.
                   88  TRAN-TRANSFER-OUT  VALUE 'TRO'.
                   88  TRAN-PAYMENT       VALUE 'PMT'.
                   88  TRAN-FEE           VALUE 'FEE'.
                   88  TRAN-INTEREST      VALUE 'INT'.
                   88  TRAN-REVERSAL      VALUE 'REV'.
                   88  TRAN-ADJUSTMENT    VALUE 'ADJ'.
               10  TRAN-SOURCE-CODE       PIC X(02).
                   88  TRAN-TELLER        VALUE 'TL'.
                   88  TRAN-ATM           VALUE 'AT'.
                   88  TRAN-ACH           VALUE 'AC'.
                   88  TRAN-WIRE          VALUE 'WR'.
                   88  TRAN-ONLINE        VALUE 'OL'.
                   88  TRAN-MOBILE        VALUE 'MB'.
                   88  TRAN-BATCH         VALUE 'BT'.
           05  TRAN-AMOUNT-AREA.
               10  TRAN-AMOUNT            PIC S9(11)V99
                                          USAGE COMP-3.
           05  TRAN-DATE-TIME.
               10  TRAN-DATE              PIC 9(08).
               10  TRAN-TIME              PIC 9(06).
           05  TRAN-DESCRIPTION           PIC X(40).
           05  TRAN-STATUS                PIC X(01).
               88  TRAN-POSTED            VALUE 'P'.
               88  TRAN-PENDING           VALUE 'N'.
               88  TRAN-REVERSED          VALUE 'R'.
               88  TRAN-REJECTED          VALUE 'X'.
           05  TRAN-REFERENCE             PIC X(20).
           05  TRAN-BRANCH-ID             PIC X(04).
           05  TRAN-TELLER-ID             PIC X(06).
           05  TRAN-BATCH-NUMBER          PIC X(08).
           05  TRAN-FILLER                PIC X(30).

34.3 Deposit Operations

Deposit operations encompass all the activities involved in managing deposit accounts: opening new accounts, closing existing accounts, modifying account attributes, placing and releasing holds, and handling dormant accounts. In a mainframe banking environment, these operations are performed by COBOL programs that access the account master VSAM file.

Account Opening

Opening a new account involves creating a record in the account master file. The COBOL program must:

1. Validate the customer information (CIF number, name, tax ID).
2. Generate or validate the new account number.
3. Set default values for the account type (interest rate, daily limits, overdraft limit).
4. Initialize all balance fields to zero (or to the initial deposit amount if provided).
5. Set the account status to active and record the open date.
6. Write the new record to the VSAM KSDS file.
7. Generate audit trail records.

The following code excerpt from Example 01 illustrates the account opening logic:

       2100-OPEN-ACCOUNT.
           MOVE WS-NEW-ACCT-NUMBER  TO ACCT-NUMBER
           MOVE WS-CIF-NUMBER       TO ACCT-CIF-NUMBER
           MOVE WS-TAX-ID           TO ACCT-TAX-ID
           MOVE WS-LAST-NAME        TO ACCT-NAME-LAST
           MOVE WS-FIRST-NAME       TO ACCT-NAME-FIRST
           MOVE WS-MIDDLE-INIT      TO ACCT-NAME-MIDDLE
           MOVE WS-ACCT-TYPE        TO ACCT-TYPE-CODE
           MOVE SPACES              TO ACCT-SUB-TYPE
           MOVE 'A'                 TO ACCT-STATUS-CODE
           MOVE WS-CURRENT-DATE     TO ACCT-OPEN-DATE
           MOVE ZEROES              TO ACCT-CLOSE-DATE
           MOVE WS-CURRENT-DATE     TO ACCT-LAST-ACTIVITY
           MOVE ZEROES              TO ACCT-LEDGER-BAL
           MOVE ZEROES              TO ACCT-AVAIL-BAL
           MOVE ZEROES              TO ACCT-HOLD-AMT
           WRITE ACCT-MASTER-RECORD
               INVALID KEY
                   SET WS-WRITE-ERROR TO TRUE
                   DISPLAY 'DUPLICATE ACCOUNT: '
                           WS-NEW-ACCT-NUMBER
           END-WRITE
           .

Account Closing

Closing an account is more complex than opening one because the program must verify several preconditions:

• The account balance must be zero (or the program must generate a closing disbursement).
• There must be no outstanding holds or pending transactions.
• The account must not have any linked services (overdraft protection, automatic payments) that must be canceled first.
• Regulatory requirements may mandate that certain records be retained for a specified period.

Rather than physically deleting the record from the VSAM file, most banks set the status code to 'C' (closed) and record the closing date. The closed record remains in the file for regulatory and audit purposes, typically for seven to ten years.

Hold and Freeze Management

Banks place holds on accounts for several reasons:

• Deposit holds: When a customer deposits a check, the bank may hold the funds until the check clears, as required by Regulation CC. The hold amount reduces the available balance but does not affect the ledger balance.
• Legal holds: A court order or regulatory agency may require the bank to freeze all or part of an account balance. The program sets the status to 'F' (frozen) and records the hold details.
• Suspicious activity holds: If the bank's monitoring systems detect potential fraud or money laundering, the account may be frozen pending investigation.

The available balance calculation always reflects holds:

           COMPUTE ACCT-AVAIL-BAL =
               ACCT-LEDGER-BAL
             - ACCT-HOLD-AMT
             + ACCT-PENDING-CR
             - ACCT-PENDING-DR
           END-COMPUTE

Dormant Account Processing

An account is classified as dormant when it has had no customer-initiated activity for a specified period, typically twelve to twenty-four months depending on state law. Banks are required by state escheatment laws to eventually turn over unclaimed funds to the state.

Dormant account processing is a batch operation that runs monthly. The COBOL program reads through the entire account master file, identifies accounts whose last activity date exceeds the dormancy threshold, and changes their status to 'D'. Additional processing generates the required notifications to customers and, after the full escheatment period expires, transfers the funds to the appropriate state agency.

34.4 Transaction Processing

Transaction processing is the core function of any banking system. Every deposit, withdrawal, transfer, payment, fee, and interest posting flows through the transaction processing engine. In a mainframe environment, transaction processing occurs in two modes: real-time (online, through CICS) and batch (during the nightly processing cycle).

Transaction Types

The following table summarizes the major transaction types and their effect on account balances:

Transaction Validation

Before a transaction can be posted, it must pass a series of validation checks. The validation logic in a typical COBOL program includes:

Account existence and status check:

           READ ACCT-MASTER-FILE INTO ACCT-MASTER-RECORD
               KEY IS TRAN-ACCT-NUMBER
               INVALID KEY
                   SET WS-ACCT-NOT-FOUND TO TRUE
                   MOVE 'ACCOUNT NOT FOUND' TO WS-REJECT-REASON
                   PERFORM 9100-WRITE-REJECT
                   GO TO 2000-PROCESS-EXIT
           END-READ

           IF ACCT-CLOSED
               MOVE 'ACCOUNT IS CLOSED' TO WS-REJECT-REASON
               PERFORM 9100-WRITE-REJECT
               GO TO 2000-PROCESS-EXIT
           END-IF

           IF ACCT-FROZEN
               IF NOT TRAN-DEPOSIT
                   MOVE 'ACCOUNT IS FROZEN' TO WS-REJECT-REASON
                   PERFORM 9100-WRITE-REJECT
                   GO TO 2000-PROCESS-EXIT
               END-IF
           END-IF

Sufficient funds check for debits:

           IF WS-IS-DEBIT-TRAN
               IF TRAN-AMOUNT > ACCT-AVAIL-BAL
                   IF ACCT-OD-LIMIT > ZEROES
                       IF TRAN-AMOUNT >
                          (ACCT-AVAIL-BAL + ACCT-OD-LIMIT)
                           MOVE 'EXCEEDS OVERDRAFT LIMIT'
                               TO WS-REJECT-REASON
                           PERFORM 9100-WRITE-REJECT
                           GO TO 2000-PROCESS-EXIT
                       END-IF
                   ELSE
                       MOVE 'INSUFFICIENT FUNDS'
                           TO WS-REJECT-REASON
                       PERFORM 9100-WRITE-REJECT
                       GO TO 2000-PROCESS-EXIT
                   END-IF
               END-IF
           END-IF

Daily limit check:

           IF TRAN-WITHDRAWAL OR TRAN-TRANSFER-OUT
               ADD TRAN-AMOUNT TO ACCT-DAILY-W-USED
               IF ACCT-DAILY-W-USED > ACCT-DAILY-W-LIMIT
                   MOVE 'DAILY WITHDRAWAL LIMIT EXCEEDED'
                       TO WS-REJECT-REASON
                   SUBTRACT TRAN-AMOUNT FROM ACCT-DAILY-W-USED
                   PERFORM 9100-WRITE-REJECT
                   GO TO 2000-PROCESS-EXIT
               END-IF
           END-IF

Posting Order: Credits Before Debits

Banks typically post credits before debits within the same batch cycle. This posting order maximizes the available balance before debits are applied, reducing the number of overdraft situations and the associated fees. The posting order is enforced by sorting the transaction file before processing:

1. Credits (deposits, transfers in, interest)
2. Debits by descending amount (largest debits first, or by transaction type priority)

This ordering is not arbitrary -- it is governed by Regulation E and the bank's deposit agreement with the customer. Some banks have faced regulatory scrutiny and class-action lawsuits over posting order practices that appeared designed to maximize overdraft fee revenue.

Memo Post vs. Final Post

A memo post (also called a "pre-posting" or "hold") temporarily adjusts the available balance to reflect a pending transaction. The ledger balance is not changed. Memo posts are used for:

• ATM withdrawals that are authorized in real time but posted in batch
• Debit card authorizations at point of sale
• Check holds under Regulation CC

A final post permanently updates both the ledger balance and the available balance, creates the permanent transaction history record, and generates the general ledger entries. Final posting typically occurs during the nightly batch cycle.

The following code shows the balance update logic for a final post:

       3000-POST-TRANSACTION.
           EVALUATE TRUE
               WHEN TRAN-DEPOSIT
               WHEN TRAN-TRANSFER-IN
               WHEN TRAN-INTEREST
                   ADD TRAN-AMOUNT TO ACCT-LEDGER-BAL
                   ADD TRAN-AMOUNT TO ACCT-AVAIL-BAL
                   ADD 1 TO WS-CREDIT-COUNT
                   ADD TRAN-AMOUNT TO WS-CREDIT-TOTAL

               WHEN TRAN-WITHDRAWAL
               WHEN TRAN-TRANSFER-OUT
               WHEN TRAN-PAYMENT
               WHEN TRAN-FEE
                   SUBTRACT TRAN-AMOUNT FROM ACCT-LEDGER-BAL
                   SUBTRACT TRAN-AMOUNT FROM ACCT-AVAIL-BAL
                   ADD 1 TO WS-DEBIT-COUNT
                   ADD TRAN-AMOUNT TO WS-DEBIT-TOTAL

               WHEN TRAN-REVERSAL
                   PERFORM 3100-PROCESS-REVERSAL

               WHEN TRAN-ADJUSTMENT
                   PERFORM 3200-PROCESS-ADJUSTMENT
           END-EVALUATE

           MOVE 'P'             TO TRAN-STATUS
           MOVE WS-CURRENT-DATE TO ACCT-LAST-ACTIVITY

           REWRITE ACCT-MASTER-RECORD
               INVALID KEY
                   DISPLAY 'REWRITE ERROR: ' TRAN-ACCT-NUMBER
                   ADD 1 TO WS-ERROR-COUNT
           END-REWRITE
           .

See Example 02 (Transaction Posting) for the complete working program that implements this logic with full validation and audit trail generation.

34.5 Payment Systems

Modern banking involves multiple payment channels, each with its own message formats, processing rules, and settlement mechanisms. COBOL programs process the vast majority of payment transactions in the United States, particularly those flowing through the ACH network and the Fedwire system.

ACH (Automated Clearing House)

The ACH network is the backbone of electronic payments in the United States, processing over 30 billion transactions per year with a total value exceeding $75 trillion. ACH handles direct deposit of payroll, Social Security payments, tax refunds, mortgage payments, utility payments, business-to-business payments, and consumer bill payments.

NACHA File Format

ACH transactions are transmitted in a standardized file format defined by NACHA (the National Automated Clearing House Association). The format consists of five record types, organized hierarchically:

File Header Record (Record Type 1):

Position  Length  Contents
1         1       Record Type Code = '1'
2-3       2       Priority Code = '01'
4-13      10      Immediate Destination (routing number with space)
14-23     10      Immediate Origin (routing number or ID)
24-29     6       File Creation Date (YYMMDD)
30-33     4       File Creation Time (HHMM)
34        1       File ID Modifier ('A' through 'Z')
35-37     3       Record Size = '094'
38-39     2       Blocking Factor = '10'
40        1       Format Code = '1'
41-63     23      Immediate Destination Name
64-86     23      Immediate Origin Name
87-94     8       Reference Code

Batch Header Record (Record Type 5):

Position  Length  Contents
1         1       Record Type Code = '5'
2-4       3       Service Class Code (200=mixed, 220=credits, 225=debits)
5-20      16      Company Name
21-40     20      Company Discretionary Data
41-50     10      Company Identification
51-53     3       Standard Entry Class Code (PPD, CCD, CTX, etc.)
54-63     10      Company Entry Description
64-69     6       Company Descriptive Date
70-75     6       Effective Entry Date (YYMMDD)
76-78     3       Settlement Date (Julian)
79        1       Originator Status Code
80-87     8       Originating DFI Identification
88-94     7       Batch Number

Entry Detail Record (Record Type 6):

Position  Length  Contents
1         1       Record Type Code = '6'
2-3       2       Transaction Code (22=checking credit, 27=checking debit, etc.)
4-11      8       Receiving DFI Identification
12        1       Check Digit
13-29     17      DFI Account Number
30-39     10      Amount (in cents, right-justified)
40-54     15      Individual Identification Number
55-76     22      Individual Name
77-78     2       Discretionary Data
79        1       Addenda Record Indicator
80-94     15      Trace Number

Batch Control Record (Record Type 8) and File Control Record (Record Type 9) contain control totals, hash totals, and record counts that allow the receiving institution to verify file integrity.

The NACHA format is a fixed-length, 94-byte record format -- a natural fit for COBOL's fixed-length record processing. See Example 04 (ACH Processing) for a complete COBOL program that parses and validates a NACHA-format ACH file.

ACH Transaction Codes

The two-digit transaction code in the Entry Detail record determines what kind of transaction is being processed:

A "prenote" is a zero-dollar test transaction used to verify that the routing number and account number are valid before sending actual payments.

ACH Processing Flow

The ACH processing flow involves two banks: the Originating Depository Financial Institution (ODFI) and the Receiving Depository Financial Institution (RDFI).

1. Origination: A company (the originator) submits an ACH file to its bank (the ODFI).
2. Validation: The ODFI validates the file format, checks the routing numbers, and verifies the originator's authorization.
3. Transmission: The ODFI transmits the file to the ACH Operator (the Federal Reserve or EPN/The Clearing House).
4. Distribution: The ACH Operator sorts the transactions by receiving bank and delivers them to each RDFI.
5. Posting: The RDFI posts the transactions to customer accounts.
6. Return Processing: If a transaction cannot be posted (account closed, insufficient funds, invalid account), the RDFI returns it to the ODFI with a return reason code.
7. Settlement: The Federal Reserve settles the net amounts between the participating banks.

Wire Transfers

Wire transfers provide same-day, irrevocable transfer of funds between financial institutions. There are two primary wire transfer systems in the United States:

Fedwire: Operated by the Federal Reserve, Fedwire is the primary domestic wire transfer system. It processes over 800,000 transfers per day with a total daily value exceeding $4 trillion. Fedwire transfers are settled in real time on a gross basis (each transfer settles individually, not netted against other transfers).

SWIFT: The Society for Worldwide Interbank Financial Telecommunication operates a messaging network used by over 11,000 financial institutions in more than 200 countries. SWIFT does not transfer funds directly; it transmits standardized messages that instruct banks to transfer funds. The most common SWIFT message type for customer wire transfers is the MT103, which contains the sender's bank, the receiver's bank, the beneficiary, the amount, the currency, and various regulatory and compliance fields.

The MT103 message format uses tagged fields:

:20:  Transaction Reference Number
:23B: Bank Operation Code
:32A: Value Date / Currency / Amount
:50K: Ordering Customer
:52A: Ordering Institution
:53A: Sender's Correspondent
:54A: Receiver's Correspondent
:56A: Intermediary
:57A: Account With Institution
:59:  Beneficiary Customer
:70:  Remittance Information
:71A: Details of Charges
:72:  Sender to Receiver Information

See Example 06 (Wire Transfer) for a COBOL program that parses and validates SWIFT MT103-format messages.

Check Processing

Despite the growth of electronic payments, checks remain a significant payment instrument. Banks process over 14 billion checks per year in the United States. Check processing involves several steps:

1. Capture: The check is scanned and the MICR (Magnetic Ink Character Recognition) line at the bottom of the check is read. The MICR line contains the routing number, account number, check number, and (after encoding) the amount.

2. Image Exchange: Under the Check 21 Act (Check Clearing for the 21st Century Act), banks can exchange digital images of checks instead of physical paper checks. A substitute check (Image Replacement Document, or IRD) is the legal equivalent of the original check.

3. Clearing: Checks are cleared through the Federal Reserve, a clearinghouse, or through direct bank-to-bank exchange. The receiving bank debits the payer's account.

4. Return: If a check cannot be paid (insufficient funds, account closed, stop payment), it is returned to the depositing bank, typically within two business days.

The MICR line format is:

[Transit/Routing Number]  [Account Number]  [Check Number]  [Amount]

The routing number includes a check digit that can be validated algorithmically, as discussed in Section 34.6.

Credit and Debit Card Authorization

Card authorization is one of the few banking operations that must occur in true real time. When a cardholder presents a card at a merchant, the following occurs in approximately two seconds:

1. The merchant's point-of-sale terminal reads the card data and sends an authorization request to the merchant's acquiring bank.
2. The acquiring bank routes the request through the card network (Visa, Mastercard, etc.) to the issuing bank.
3. The issuing bank's authorization system validates the card number (using the Luhn algorithm), checks the available credit, verifies the card is not reported lost or stolen, applies fraud detection rules, and checks merchant category restrictions.
4. The issuing bank returns an authorization response (approved or declined) with an authorization code.
5. The response travels back through the card network and acquiring bank to the merchant's terminal.

On the issuing bank's mainframe, this authorization flow is typically handled by a CICS transaction that invokes a COBOL program. The program performs the validation checks, creates a memo post (authorization hold), and returns the response. The actual settlement occurs later, typically in the next business day's batch cycle.

Real-Time Payments (RTP)

Real-Time Payments, operated by The Clearing House, and FedNow, operated by the Federal Reserve, represent the newest payment channel. RTP enables immediate, irrevocable transfer of funds between participating banks, 24 hours a day, 365 days a year. Unlike ACH, which settles in batches, RTP settles each payment individually in real time.

Banks that participate in RTP must be able to process incoming payments and post them to customer accounts within seconds. This requirement has driven some banks to integrate real-time processing capabilities alongside their traditional batch-oriented COBOL systems, often through middleware that bridges the RTP network to the core banking mainframe.

34.6 Check Digit Algorithms

Check digit algorithms detect common transcription errors in numeric identifiers such as credit card numbers, account numbers, and routing numbers. These algorithms are simple mathematical tests that can be implemented efficiently in COBOL and are a fundamental part of financial data validation.

The Luhn Algorithm (Modulus 10)

The Luhn algorithm, also known as the Mod 10 algorithm, is used to validate credit card numbers, IMEI numbers, and various other identification numbers. It was created by IBM scientist Hans Peter Luhn in 1954 and is described in U.S. Patent 2,950,048.

The algorithm works as follows:

1. Starting from the rightmost digit (the check digit) and moving left, double every second digit.
2. If doubling a digit results in a value greater than 9, subtract 9 from it (equivalent to adding the two digits of the product).
3. Sum all the digits.
4. If the total modulo 10 equals 0, the number is valid.

Example: Validate the credit card number 4539 1488 0343 6467.

Original digits:  4  5  3  9  1  4  8  8  0  3  4  3  6  4  6  7
Double every 2nd: 8  5  6  9  2  4  16 8  0  3  8  3  12 4  12 7
Subtract 9 if >9: 8  5  6  9  2  4  7  8  0  3  8  3  3  4  3  7
Sum: 8+5+6+9+2+4+7+8+0+3+8+3+3+4+3+7 = 80
80 mod 10 = 0 --> VALID

The Luhn algorithm detects all single-digit errors (any one digit changed) and most transpositions of adjacent digits. It does not detect transpositions of the sequence 09 to 90 (or vice versa).

Modulus 11 for Account Numbers

Many banks use a Modulus 11 algorithm to validate account numbers. The algorithm assigns positional weights to each digit, computes a weighted sum, and checks whether the sum is divisible by 11.

A common weighting scheme uses the weights 7, 6, 5, 4, 3, 2, repeating as needed:

Account number: 1 2 3 4 5 6 7
Weights:        7 6 5 4 3 2 7
Products:       7+12+15+16+15+12+49 = 126
126 mod 11 = 5
Check digit = 11 - 5 = 6

If the result is 10, the check digit is often represented as 'X'; if the result is 11, the check digit is 0. Some implementations use different conventions.

ABA Routing Number Validation

The nine-digit ABA (American Bankers Association) routing number includes a check digit in the ninth position, calculated using a specific weighted modulus 10 algorithm:

Routing number positions: d1 d2 d3 d4 d5 d6 d7 d8 d9
Weighted sum = 3*d1 + 7*d2 + 1*d3 + 3*d4 + 7*d5 + 1*d6 + 3*d7 + 7*d8 + 1*d9

If the weighted sum is evenly divisible by 10, the routing number is valid.

Example: Validate routing number 021000021.

Digits:   0  2  1  0  0  0  0  2  1
Weights:  3  7  1  3  7  1  3  7  1
Products: 0+14+1+0+0+0+0+14+1 = 30
30 mod 10 = 0 --> VALID

See Example 03 (Check Digit Validation) for complete COBOL implementations of all three algorithms.

34.7 Statement Generation

Monthly statements are one of the most visible outputs of a banking system. Customers rely on statements to verify their transactions, track their balances, and reconcile their records. From a programming perspective, statement generation is a complex report-generation task that involves reading multiple files, sorting transactions, calculating running balances, formatting output with proper page breaks, and including regulatory disclosures.

Monthly Cycle Processing

Statement generation follows a monthly cycle determined by the statement cycle date assigned to each account. Rather than generating all statements on the last day of the month (which would create an enormous processing spike), banks distribute accounts across cycle dates throughout the month. An account with a cycle date of the 15th receives its statement covering activity from the 16th of the previous month through the 15th of the current month.

The batch processing flow for statement generation is:

1. Extract: A COBOL program reads the account master file and selects accounts whose statement cycle date matches the current processing date.
2. Transaction Pull: For each selected account, the program reads the transaction history file and extracts all transactions within the statement period.
3. Sort: Transactions are sorted by account number and transaction date.
4. Format and Print: The statement generation program reads the sorted transactions, calculates running balances, formats each page of the statement, and writes the output to a print file or an electronic delivery system.
5. Update: The account master file is updated to record the statement date and the closing balance as of the statement date.

Statement Layout

A typical bank statement includes the following sections:

• Header: Bank name, logo, customer name and address, account number, statement period, page number
• Summary: Opening balance, total deposits, total withdrawals, fees, interest earned, closing balance
• Transaction Detail: Date, description, debit amount, credit amount, running balance for each transaction
• Interest Summary: Interest rate, interest earned during the period, year-to-date interest
• Fee Summary: Itemized list of fees charged during the period
• Regulatory Disclosures: Required legal notices, Regulation E disclosures, privacy notices

Running Balance Calculation

The running balance is calculated by starting with the opening balance (the closing balance from the previous statement) and applying each transaction in chronological order:

       4000-FORMAT-TRANSACTION.
           EVALUATE TRUE
               WHEN TRAN-DEPOSIT
               WHEN TRAN-TRANSFER-IN
               WHEN TRAN-INTEREST
                   ADD TRAN-AMOUNT TO WS-RUNNING-BALANCE
                   MOVE TRAN-AMOUNT TO WS-PRT-CREDIT-AMT
                   MOVE SPACES       TO WS-PRT-DEBIT-AMT

               WHEN TRAN-WITHDRAWAL
               WHEN TRAN-TRANSFER-OUT
               WHEN TRAN-PAYMENT
               WHEN TRAN-FEE
                   SUBTRACT TRAN-AMOUNT FROM WS-RUNNING-BALANCE
                   MOVE TRAN-AMOUNT TO WS-PRT-DEBIT-AMT
                   MOVE SPACES       TO WS-PRT-CREDIT-AMT
           END-EVALUATE

           MOVE WS-RUNNING-BALANCE TO WS-PRT-BALANCE
           PERFORM 4100-WRITE-DETAIL-LINE
           .

See Example 05 (Statement Generation) for the complete working program.

34.8 Regulatory Compliance

Banking is one of the most heavily regulated industries in the world. COBOL programs must implement and enforce regulatory requirements at every level, from individual transaction validation to enterprise-wide reporting. Understanding these regulations is essential for any programmer working on banking systems.

BSA/AML (Bank Secrecy Act / Anti-Money Laundering)

The Bank Secrecy Act of 1970, as amended by the USA PATRIOT Act of 2001, requires banks to maintain programs to detect and report suspicious activity that may indicate money laundering, terrorist financing, or other financial crimes.

Key requirements that affect COBOL programs:

Currency Transaction Reports (CTRs): Banks must file a CTR for any cash transaction (deposit, withdrawal, exchange) exceeding $10,000. Multiple transactions by the same customer on the same day must be aggregated -- a practice known as "structuring detection." If a customer makes three cash deposits of $4,000 each at different branches on the same day, the total ($12,000) triggers a CTR.

The COBOL program that detects CTR-reportable transactions typically runs during the nightly batch cycle:

           IF WS-DAILY-CASH-TOTAL > 10000.00
               PERFORM 7100-GENERATE-CTR-RECORD
               ADD 1 TO WS-CTR-COUNT
           END-IF

Suspicious Activity Reports (SARs): Banks must file SARs when they detect activity that appears unusual or suspicious. Automated detection programs look for patterns such as:

• Transactions just below the $10,000 CTR threshold (structuring)
• Rapid movement of funds through an account (funneling)
• Large round-dollar wire transfers to high-risk jurisdictions
• Unusually large transactions relative to the customer's profile

OFAC Screening: The Office of Foreign Assets Control maintains lists of individuals, entities, and countries subject to U.S. economic sanctions. Banks must screen all transactions, account openings, and wire transfers against OFAC lists. COBOL programs that process wire transfers typically include an OFAC screening step that compares beneficiary names and account numbers against the Specially Designated Nationals (SDN) list.

Regulation E (Electronic Fund Transfers)

Regulation E, issued by the Federal Reserve under the Electronic Fund Transfer Act, governs consumer electronic fund transfers, including ATM transactions, debit card payments, ACH transfers, and online banking transactions. Key requirements include:

• Error resolution procedures: Banks must investigate and resolve claimed errors within specific timeframes (10 business days, extendable to 45 days for certain cases).
• Unauthorized transfer liability limits: Consumer liability for unauthorized transfers depends on how quickly the consumer reports the loss.
• Transaction receipts: Banks must provide receipts for electronic fund transfers at the time of the transaction.
• Periodic statements: Banks must provide regular statements showing all electronic fund transfers.

Regulation CC (Availability of Funds)

Regulation CC governs how quickly banks must make deposited funds available to customers. The regulation specifies:

• Next-day availability for cash deposits, electronic payments, U.S. Treasury checks, and certain other items.
• Two-day availability for local checks.
• Extended holds permitted for new accounts, large deposits (over $5,525), redeposited checks, and accounts with repeated overdrafts.

COBOL programs that process check deposits must calculate the appropriate hold period and set the hold release date in the account master file.

34.9 Batch Processing in Banking

The nightly batch cycle is the heartbeat of a banking system. While online systems handle real-time transactions during business hours, the batch cycle performs the heavy lifting of end-of-day processing: posting transactions, accruing interest, assessing fees, generating statements, and producing regulatory reports.

End-of-Day Cycle

A typical nightly batch cycle consists of the following steps, executed in sequence through JCL job streams:

1. Cutoff Processing: Close the online system to new transactions (or switch to a "next day" processing date).
2. Transaction Sorting: Sort all pending transactions by account number, then by posting priority (credits before debits).
3. Transaction Posting: Post all pending transactions to the account master file, updating balances and creating history records.
4. Overdraft Processing: Identify accounts that went negative during posting. Attempt automatic transfers from linked accounts (overdraft protection). Assess overdraft fees for remaining negative balances.
5. Interest Accrual: Calculate and accrue daily interest for all interest-bearing accounts.
6. Interest Posting: On the designated posting day (monthly, quarterly), post accrued interest to account balances.
7. Fee Assessment: Apply monthly maintenance fees, minimum balance fees, excessive transaction fees, and other charges.
8. Statement Generation: Generate statements for accounts whose cycle date matches the current date.
9. Regulatory Reporting: Generate CTR records, SAR triggers, OFAC screening, and other compliance data.
10. General Ledger Update: Post all day's activity to the general ledger, ensuring debits equal credits.
11. Backup: Back up all master files to tape or disk.
12. Reconciliation: Run control total reports to verify that all processing balanced.

Interest Accrual

Interest on savings accounts, money market accounts, and CDs is typically calculated daily and posted monthly or quarterly. The daily interest accrual formula is:

Daily Interest = Balance * (Annual Rate / Days in Year)

In COBOL:

       6000-ACCRUE-INTEREST.
           IF ACCT-SAVINGS OR ACCT-MONEY-MARKET OR ACCT-CD
               IF ACCT-LEDGER-BAL > ZEROES
                   COMPUTE WS-DAILY-INTEREST ROUNDED =
                       ACCT-LEDGER-BAL *
                       (ACCT-INT-RATE / WS-DAYS-IN-YEAR)
                   ADD WS-DAILY-INTEREST TO ACCT-INT-ACCRUED
               END-IF
           END-IF
           .

Note the use of ROUNDED to handle the fractional cent that results from the division. Banking regulations specify how rounding must be applied, and the bank's interest calculation methodology must be consistent with the Annual Percentage Yield (APY) disclosed to customers.

Fee Assessment

Fee assessment programs apply charges based on account attributes and activity. Common fees include:

• Monthly maintenance fee (waived if minimum balance is maintained)
• Excessive transaction fee (savings accounts are limited to 6 withdrawals per month under Regulation D)
• Overdraft fee (typically $25-$35 per occurrence)
• ATM surcharge (for using out-of-network ATMs)
• Wire transfer fee
• Stop payment fee
• Paper statement fee

The fee assessment COBOL program typically uses a fee schedule table that is loaded from a configuration file at the start of the batch run, making it easy to change fee amounts without modifying the program.

34.10 COBOL Data Structures for Banking

Banking programs share data structures through copybooks -- reusable COBOL source members that define record layouts, condition names, and constants. A well-organized copybook library is essential for consistency across the hundreds of programs in a core banking system.

Shared Copybook Strategy

A typical banking system maintains copybooks organized by function:

By defining the account master record layout in a single copybook, any change to the layout (adding a field, changing a field size) needs to be made in only one place. All programs that COPY the copybook will pick up the change when they are recompiled.

Using Copybooks in This Chapter's Examples

The examples in this chapter define their record layouts inline for clarity and self-containment. In a production banking environment, these layouts would be replaced with COPY statements:

       FD  ACCOUNT-MASTER-FILE
           RECORD CONTAINS 300 CHARACTERS.
       01  ACCT-MASTER-RECORD.
           COPY CPYACCT.

This practice, discussed in detail in Chapter 18 (Copybooks and Code Reuse), is fundamental to maintainable banking systems. When you encounter account and transaction record layouts in this chapter's examples, recognize that they represent simplified versions of what would be shared copybook definitions in production.

34.11 Chapter Summary

Banking and payment systems represent the quintessential COBOL application domain. The language's decimal arithmetic, file processing capabilities, and self-documenting syntax make it ideally suited for financial transaction processing. In this chapter, you have learned:

• The architecture of a core banking system, including the Customer Information File, account master file, transaction processing engine, and payment systems.
• How to design COBOL record layouts for account master files and transaction files, using packed decimal (COMP-3) for monetary fields and condition names (88-level) for status codes.
• The lifecycle of deposit operations: account opening, closing, hold management, and dormant account processing.
• Transaction processing fundamentals: validation rules, posting order (credits before debits), and the distinction between memo posts and final posts.
• Payment system processing, including the NACHA file format for ACH transactions, SWIFT MT103 for wire transfers, MICR line format for check processing, and the card authorization flow.
• Check digit algorithms: the Luhn algorithm for credit cards, Modulus 11 for account numbers, and the ABA routing number validation algorithm.
• Statement generation: monthly cycle processing, running balance calculation, page formatting, and regulatory disclosures.
• Regulatory compliance requirements: BSA/AML (CTR and SAR reporting), OFAC screening, Regulation E, and Regulation CC.
• The end-of-day batch cycle: transaction posting, interest accrual, fee assessment, statement generation, and reconciliation.
• The role of shared copybooks in maintaining consistent data structures across a banking system's COBOL programs.

The examples that accompany this chapter provide complete, working COBOL programs that demonstrate each of these concepts. As you work through the examples and exercises, remember that the programs you are writing represent simplified versions of the systems that move trillions of dollars every day. The patterns you learn here -- validation before posting, credits before debits, control total reconciliation, and comprehensive audit trails -- are the same patterns used in production banking systems around the world.

In the next chapter, we will explore insurance and government systems, another major domain where COBOL programs process millions of records daily for policy administration, claims processing, benefits calculation, and regulatory compliance.