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.
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).
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:
XXXXis the Federal Reserve Routing Symbol
YYYYis the ABA Institution Identifier
Cis a check digit
There’s a decent amount of information available online about the format of the Federal Reserve Routing Symbol, but a quick recap:
00indicates the US Government
12correspond to the 12 Federal Reserve banks (e.g.
02is New York)
32correspond to “thrift” institutions in their corresponding Federal Bank regions (
X - 20, so
22indicates a thrift institution registered with the NY Fed)
72are Electronic Transaction Identifiers and follow the same Federal Bank pattern as thrifts (
X - 60, so
61indicates something like a payment processor or clearinghouse registered with the Boston Fed)
80indicates a travelers’ check
0if the bank is in the city of the associated Fed bank, and
9if 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.
0also 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:
1010indicates 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).
6724indicates 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.
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.
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:
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.
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:
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:
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:
YYMMDDformat. Y2K, here we come!
HHMMformat. 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.
200— Mixed debits and credits
220— Credits only
225— Debits only
PPDfor “prearranged payment and deposit”; direct deposit and utility auto-pay fall into this7.
WEBfor “Internet-initiated entry”; online purchases and online bank-to-bank transfers may fall into this.
WEB) is open to interpretation. NACHA issued some guidance in 2007 on which codes to use, but it isn’t exhaustive.
IATfor international ACH transactions,
MTEfor machine transfer entries (i.e., ATM transactions), and
ENRfor automated enrollment entries. Appendix B in the NACHA operating guidelines8 appears to have the full list.
Some other interesting bits:
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?
Finally, the actual entries. Taking a closer look at
PPD entries (by way of example):
$$$$$$$$cc, meaning that the largest (dollar) amount transmittable via a single plain old ACH entry is $99,999,999.999. It may be possible to send larger amounts via an addenda; I’m not sure.
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
_ 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 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:
1, meaning that returns are required to include additional addenda record(s)11.
Each addenda record carries much of the remaining state necessary to process the return:
YYMMDD) field is used for return codes
R15(which indicate death, presumably after a
DNEhas 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.
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 return12.
NACHA provides some information on
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:
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.
I’ve linked to a miscellanea of resources above, but here are some others that I referenced while writing the above:
Some topics I want to look at in the future:
MTESEC 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.
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. ↩
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. ↩
And can apparently see your entire transaction history, which is just great. ↩
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. ↩
And maybe some non-monetary requests as well? ↩
It looks like most return records require a single addenda, while IAT returns require eight(!). There may be other, additional exceptions that I missed. ↩
Supplement #2-2012 to the 2013 NACHA corporate rules indicates this. ↩
Article 3, Subsection 188.8.131.52 in the 2013 corporate rules. ↩