ENOSUCHBLOG

Programming, philosophy, pedaling.


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:

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:

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

By way of example:

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:

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:

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 all2 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 "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:

ACH records

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

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

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:

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:

Some other interesting bits:

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

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):

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 credit10 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 addenda record carries much of the remaining state necessary to process the return:

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:

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

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:

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 return13 (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:

Future topics

Some topics I want to look at in the future:


  1. The Wikipedia page for the Expedited Funds Availability Act claims that there is (as of 2010) only one "check processing region" for the entire country. 

  2. I don't know whether or not the Fed requires banks to conduct interbank settlement via ACH, but I suspect that they don't as long as everything gets reported somewhere — anecdotally, my bank has told me that they can settle some transactions faster than ACH by conducting them "directly" via the bank that they themselves bank with. 

  3. A contrived example, to the best of my understanding: company A banks with B, C, and D. Instead of handling credits and debits with each of B, C, and D individually, A uses B as their ODFI and sends all of their transactions as a batched ACH file. 

  4. And can apparently see your entire transaction history, which is just great. 

  5. But not really: this HN post relates that up to 96 (for CRLF) occurs in the wild. 

  6. For most US citizens, their TIN is their SSN. Companies can also be issued their own TINs in the form of EINs

  7. It looks like utility payments can also be coded as CIE(+), the "+" indicating the presence of an addenda record. It's not clear why this would be used over PPD(+) or vice versa. 

  8. NACHA restricts access to their operating guidelines, because of course they do. You can find them online if you're smart about it, or you cough up $99 to buy the latest edition from their store

  9. The batch and file control records each use 12 columns (i.e., $$$$$$$$$$cc) for their debit and credit sums, meaning that an ACH file can have up to 100 maxed-out records. That's just under $1 trillion USD, so individual ACH files probably don't get anywhere near that. 

  10. And maybe some non-monetary requests as well? 

  11. It looks like most return records require a single addenda, while IAT returns require eight(!). There may be other, additional exceptions that I missed. 

  12. Supplement #2-2012 to the 2013 NACHA corporate rules indicates this. 

  13. Article 3, Subsection 3.8.5.2 in the 2013 corporate rules.