ENOSUCHBLOG

Programming, philosophy, pedaling.

• Home
• Tags
• Series
• Favorites
• Archive
• Main Site

A (shallow) dive into the American banking system

Dec 25, 2019     Tags: curiosity    

This post is a collection of miscellaneous notes that I’ve collected about the American banking system. Some caveats:

• It’s based on ~internet research~, and so is only as accurate as whatever I can piece together from different sources.
• It focuses primarily on the common cases of routable accounts, i.e. checking and savings.

I’ve marked areas where I have outstanding questions — if you know the answers to these questions (or know where I could find answers), I’d appreciate it.

Account identification

Accounts are uniquely identified by the tuple of their routing number and account number.

An account tied to a debit card is additionally identified by a payment card number (alternatively primary account number).

Routing numbers

An account’s routing number (or routing transit number) identifies the holding institution, and is public (i.e., not sensitive) information. Routing numbers are nine digits long and are maintained and allocated by the American Banking Association (the “ABA” in “ABA RTN”).

The ABA publishes its routing number policy, which contains some interesting facts:

• Every bank has at least one ABA RTN, which is its principal office routing number.
• Banks can have up to four additional routing numbers (for a total of five), and may have even more with special approval.
• The nine digits of an ABA RTN are structured as XXXXYYYYC, where:
  • XXXX is the Federal Reserve Routing Symbol
  • YYYY is the ABA Institution Identifier
  • C is a check digit
• Federal Reserve account numbers look like ABA RTNs, but are neither indexed by the ABA nor ACH-routable. This apparently confuses enough bankers to be worthy of a dedicated Q&A item in the ABA RTN policy.

There’s a decent amount of information available online about the format of the Federal Reserve Routing Symbol, but a quick recap:

• The first two digits can indicate a few different things, but fall into some common cases:
  • 00 indicates the US Government
  • 01 through 12 correspond to the 12 Federal Reserve banks (e.g. 02 is New York)
  • 21 through 32 correspond to “thrift” institutions in their corresponding Federal Bank regions (X - 20, so 22 indicates a thrift institution registered with the NY Fed)
  • 61 through 72 are Electronic Transaction Identifiers and follow the same Federal Bank pattern as thrifts (X - 60, so 61 indicates something like a payment processor or clearinghouse registered with the Boston Fed)
  • 80 indicates a travelers’ check
• The third digit is (supposedly) the “check processing center” originally assigned to the bank that holds the routing number. It’s not clear whether a Fed branch can have more than one check processing center, or whether the branch itself is the center. It’s also not clear whether this number is meaningful anymore¹.
• The fourth digit is 0 if the bank is in the city of the associated Fed bank, and 1 through 9 if it is in another state in the Fed bank’s district. This site has tables of the numbers, and suggests that the last digit is not unique to each state in the Fed bank’s district. 0 also serves a (historical?) double purpose of indicating immediate funds availability, since the institution is in the same city as its associated Fed bank. It’s not clear whether this is still true.

By way of example:

• 1010 indicates a regular banking institution in the 10th district whose checks are/were originally processed by the first center in the Fed’s city (Kansas City, in this case).
• 6724 indicates a cooperative bank in the 7th district whose checks are/were originally processed by the second center in a branch city (Detroit, in this case).

The ABA Institution Identifier doesn’t appear to have any (public) structure, other than uniquely identifying the institution relative to the Fed district it belongs to.

An (official) table of full routing numbers for the Federal Reserve banks themselves is conveniently provided here.

The ABA also partners with registrars like Accuity to maintain and sell complete copies of the routing database for reference by financial institutions. In particular, Accuity maintains and sells The ABA Key to Routing Numbers (better known as the “keybook”), which contains a list of all allocated routing numbers as well as a record of recent changes (i.e., new and recently deactivated RTNs). I couldn’t find a copy of the keybook online.

The Fed apparently provides a database called the “E-Payments Routing Directory” for free, but only via FedLine, which is some kind of business services portal. They’re kind enough to provide a letter template for requesting that your banking institution request the download on your behalf, but I haven’t done it yet.

Someone was kind enough to upload a copy of the routing directory (as of 2015) to GitHub here.

Account numbers

Unlike routing numbers, account numbers have no fixed length or internal structure standards. US banks don’t confirm to IBAN.

According to this SO post NACHA stipulates that account numbers are between 4 and 17 digits for ACH routing purposes, but there’s no requirement (as far as I can tell) that an account be ACH-routable.

There’s something called a Universal Payment Identification Code (“UPIC”) that can apparently stand in for the tuple of (ABA RTN, account number) for NACHA (but not FedWire ACH) purposes. There’s a Wiki page; I didn’t look into them much beyond that.

PCNs/PANs and payment cards

Unlike account numbers, payment card numbers (or primary account numbers) are structured.

Also unlike account numbers, they don’t uniquely identify a particular account — instead, they identify a card tied to a particular entity (e.g., an individual or company) at a particular financial institution. That entity, in turn, may have multiple accounts accessible via their PCN (e.g. being able to access both checking and savings via a bank-supplied debit card).

PCNs (as of 2017) are between 10 and 19 digits, with the following structure:

• The first six digits are the Issuer Identification Number (IIN) which, for financial institutions, is the Bank Identification Number (BIN). Websites regularly use the IIN/BIN to indicate which card provider/issuer network the PCN belongs to, e.g. by highlighting the network’s logo during the payment process. IINs are a superset of BINs.
  • The first digit of the IIN/BIN is the major industry identifier (MII), which indicates the general industry that the issuer belongs to. Examples: 3 indicates travel and entertainment, 4 and 5 indicate general financial issuers (like banks).
• (Up to) the next twelve digits are the account identifier, which serves a function similar to the direct account number above.
• The last digit is a Luhn check digit.

Like routing numbers, IINs are maintained by the ABA and are not sensitive information. Despite not being sensitive, access to the complete IIN registry/database is restricted similarly to ABA RTNs and the “keybook”: only entities with allocated IINs have access to the official, complete register.

Despite this, there exist a plethora of third-party services and APIs, some of which are probably directly reselling the official register.

Some miscellaneous notes about PANs/PCNs:

• PAN truncation is the practice of removing or obscuring all but the last few digits of the PAN on transaction records (e.g., paper receipts).
  • PCI DSS requires that no more than 4 last digits be shown and FACTA requires that no more than 5 be shown, so 4 is common.
• As far as I can tell, there’s no explicit rule anywhere saying that a PAN/PCN’s account identifier can’t be the routable account number for the underlying bank account. There’s probably no good reason for it to be that way (since it would pointlessly complicate the process of accessing more than one account from a single payment card), but I also can’t find any evidence that it’s prohibited.

Most payment cards in the US can now perform transactions in (at least) three ways:

1. Manual imprinting using the embossed card features
2. Magnetic stripe “swipes”
3. EMV with an embedded smart chip

In-card support for contactless payments (which generally use EMV) are not particularly common yet; smartphone-based contactless systems (i.e. digital wallets like Apple Pay) have seen more adoption.

Clearing and clearinghouses

Oh boy.

In the US, virtually all² interbank credits and debits are performed (i.e., settled or “cleared”) via the Automated Clearing House, or ACH. Other countries have their own ACH systems, but for historical reasons the US’s has an (exceptionally?) complicated structure. It contains, at minimum:

• The ACH network itself, maintained by NACHA.
• The ACH operators, who receive batched transactions and dispatch them to their destination institutions.
  • There are currently two ACH operators: FedACH and the EPN. It’s not clear to my why there are two, or why one of them is private.
• ACH files, which are batched collections of structured ACH records.
  • More on the structure of these records in a bit.
• Originating and Receiving Depository Financial Institutions (ODFIs and RDFIs), which transmit and receive ACH files, respectively, from the ACH operators.
  • ODFI and RDFI refer to the direction of the ACH record, not its kind — an ODFI can issue either a credit or a debit request.
• The penultimate originating and receiving banks, which may or may not be distinct from their ODFI and/or RDFI³.
• The ultimate originator and receiver, corresponding to individual account-holding entities.

The “files” in “ACH files” is not a metaphor — settlement via ACH is actually conducted via text files containing structured records. It’s hard to find public information on the topology and structure of the actual ACH network, but ingress into it (via your ODFI) is typically done by uploading ACH files to some kind of FTP endpoint. SFTP (or FTPS) appears to be optional at most ODFIs. J.P. Morgan is kind enough to provide some details here.

ACH was designed in the financial and computing environment of the 1960s, and it shows:

• As the batching of ACH records into files implies, actual interbank settlement is done in batches: ODFIs (generally) send at least one batch per 24 hour cycle, and most do at least two (my bank implies that it does several, ending at 4PM each day). RDFIs do the same.
• Complete settlement is not guaranteed to occur at the end of the initial ODFI-RDFI trip — the RDFI has up to 48 hours (and maybe more?) to evaluate the transaction and send a return code indicating a bad transaction. Combined with bad cycle timing and dead days (e.g., Sundays and holidays), this means that settlement can easily take several calendar days before holds even get involved. The gusto blog has an excellent set of diagrams that visualize this.
• Authentication (i.e., proving that you have control over an account) is done in a number of hacky ways, including sending small transactions that the owner must correctly report to the authenticating party. Plaid provides a login-based alternative to some of these⁴; they document some of the account verification options here.

ACH records

The individual ACH records in an ACH file are plain text, and are (apparently) limited to 94 columns/characters⁵.

When everything goes right, they take one of six forms:

• File header
• Batch header
• Entry detail
• Entry addenda
• Batch control
• File control

All records are required, except (apparently) for addenda records. I can’t find a ton of information about those, but this random PDF says that they’re optional and only get used for CCD+ and CTX, which are apparently corporate-to-corporate transactions.

File and batch header/control form a nested structure around individual entries, like so:

1
2
3
4
5
6
7
8
9
10
11
12
File header
  Batch header 1
    Entry 1
    Entry 2
    ...
    Entry N
  Batch control
  ...
  Batch header N
    ...
  Batch control
File control

File and batch headers contain metadata about their respective children, including origin and destination routing numbers (in the file header) and information about the kind of individual entries (in the batch header). The PDF above covers a lot of the individual field details; this one from US Bank (concerning international ACH transactions) is also good. I’ll avoid going through most of the header fields as a result, but a few stand out:

• In the file header:
  • The creation date is in YYMMDD format. Y2K, here we come!
  • The creation time is in HHMM format. It’s not clear whether timezones are sidechanneled elsewhere, or what it means for the ACH processor to receive a file who’s header indicates the future.
  • The immediate destination is an ABA RTN, while the immediate origin is usually a US tax identification number (TIN)⁶. TINs are usually no longer than 9 digits; some resources indicate that the immediate destination gets pre-padded with 1s to the appropriate 10-digit length. US Bank’s document hints that they might be using the pre-pad digit(s) to store additional state. Scary.
• In the batch header:
  • The service class code indicates the disposition of the individual entries. It can be (at least) one of:
    • 200 — Mixed debits and credits
    • 220 — Credits only
    • 225 — Debits only
  • The standard entry class indicates the kind of entries in the batch. This page has a non-exhaustive list of entry classes, of which a few stand out:
    • PPD for “prearranged payment and deposit”; direct deposit and utility auto-pay fall into this⁷.
    • WEB for “Internet-initiated entry”; online purchases and online bank-to-bank transfers may fall into this.
    • There doesn’t appear to be any actual sanity checking of the SEC code used, especially since the selection (e.g., PPD vs. CIE vs. WEB) is open to interpretation. NACHA issued some guidance in 2007 on which codes to use, but it isn’t exhaustive.
    • There are a decent number of codes that are harder to find information on: IAT for international ACH transactions, MTE for machine transfer entries (i.e., ATM transactions), and ENR for automated enrollment entries. Appendix B in the NACHA operating guidelines⁸ appears to have the full list.

Some other interesting bits:

• Not all SEC codes are monetary in nature: the DNE (for death notification entry) code allows the government to notify banks of the death of an individual. An open question: what mechanism prevents banks (or anybody with an ODFI agreement) from issuing arbitrary death entries?
• Most of the routing number fields in ACH records appear to be only 8 digits, which I’m guessing means that the check digit doesn’t get included. Only the actual entry records appear to include the check digit, as a separate field.
• The entry hash fields on control records appear to just be (truncated) sums of the relevant (8-digit-only) ABA RTNs on entry records. Not a great hash.

Finally, the actual entries. Taking a closer look at PPD entries (by way of example):

• The amount in an entry record is 10 columns and is formatted as $$$$$$$$cc, meaning that the largest (dollar) amount transmittable via a single plain old ACH entry is $99,999,999.99⁹. It may be possible to send larger amounts via an addenda; I’m not sure.
• In addition to the receiver’s account number, the individual identification number also provides an (optional) 15 digit identifier for the receiving individual. I don’t know what this is used for, but one guess is disambiguating the acting individual during a transaction on a joint account.
• The trace number field provides a (supposedly) transaction-unique 15-digit number, to be used in the event of an inquiry. It’s not clear whether this number is globally unique or only unique to the ODFI (and RDFI?).

The batch and file control records include metadata about the number of records and debit/credit sums in the preceding block and entire file, respectively. The batch control record also repeats a good deal of information present in the batch header (e.g. the company identifier and ODFI routing number). Each control record also keeps track of the total number of addenda seen in its preceding scope. All told, this supplies a decent amount of redundancy.

By way of example, here’s an entire contrived ACH file containing a single credit via a PPD record (with _ representing a blank for field separation and spacing purposes):

1
2
3
4
5
101_02100002114444444441912231330A094101JPMORGAN CHASE_________MY FAKE COMPANY NAME___00000000
5220MYFAKECONAME____DISCRETIONARYXXXDATA1444444444PPDYEAR BONUSDEC 31191231___1021000080000001
622021000021888888888888_____0000100000999999999999999JOHN DOE______________XX0123451234512345
822000000100021000020000000000000000001000001444444444_________________________102100000000001
9000001000001000000010002100002000000000000000000100000_______________________________________

All of that to represent just one $1000 USD deposit. Note that the 94-column records are separated by newlines here for readability — it seems like a lot of ACH software handles this appropriately, but the more correct wire representation would be a constant stream.

As hinted above, RDFIs (or anybody along the transaction chain, really) can countermand a particular debit or credit¹⁰ by issuing a return record. Returns are normal entry records, and their format is documented in Appendix 4 of the NACHA corporate guidelines. They mostly mirror (in terms of contents) the records they countermand, with a few interesting additions:

• Each return entry has its own two-digit transaction code, which indicates the disposition of the return. I found a public list here; they’re also in Appendix 3 of the NACHA guidelines.
• The addenda record indicator for a return is always 1, meaning that returns are required to include additional addenda record(s)¹¹.
• Each return has its own new trace number, allowing it to be audited much like normal entries.

Each addenda record carries much of the remaining state necessary to process the return:

• The original entry trace number reflects the number for the original record being countermanded.
• The date of death (formatted YYMMDD) field is used for return codes R14 and R15 (which indicate death, presumably after a DNE has been issued). My best guess is that it’s meant to allow financial institutions to analyze their own records for transactions that post-date the death.
• The addenda information field appears to be discretionary, and is a little under half (44 columns) the size of the entire record.

Depending on the kind of return, the RDFI has either 24 hours (business hours?), 60 days, or an indeterminate amount of time to issue a return.

Because nothing in life is simple, return entries themselves can be dishonored and countermanded with different return codes. Some examples:

• R61 — Misrouted return
• R67 — Duplicated return
• R68 — Untimely return
• R69 — Incorrect information

ODFIs must submit a dishonored return within 5 banking days of the settlement date for the original return¹².

NACHA provides some information on R69 here (and chides ODFIs for misusing it). In particular, it looks like R69 uses its addenda information to encode which piece(s) of information are at fault, separated by asterisks. So:

1
02*03

Indicates a return that has been dishonored for incorrectly specifying the original entry trace and the dollar amount to be returned.

Finally the cycle is completed with yet more return codes, this time for dishonoring (or “contesting”) dishonored returns. Confusing. R71 (misrouted dishonored return), R76 (no errors found), and R77 (non-acceptance of R62) stand out.

RDFIs have two banking days after the settlement of the dishonored return¹³ (i.e., up to 7 banking days after the settlement of the original return, and ??? days after the settlement of the original request) to issue a contested dishonored return.

Other resources

I’ve linked to a miscellanea of resources above, but here are some others that I referenced while writing the above:

• NPR Planet Money, Episode 489 (Transcript)

• 2010 ACH Corporate User Quick Reference Card

• This entire HN thread

Future topics

Some topics I want to look at in the future:

• ATMs
  • The MTE SEC used for ATM transactions seems to have some interesting internal formatting for representing where exactly an ATM transaction occurred. I think these are embedded in addenda records. Reference page circa 72 of the (2013) NACHA operating guidelines.
• OFC/OFX
• ChexSystems
• Virtual PANs (e.g., Apple Pay)
• PayCo, Fedwire and CHIPS
• Chip/EMV and contactless payments
• CVV, CVV2, and card verification services
• KYC and Suspicious Activity Reports (SARs)