Standardize ABA RTN (Routing transit number)

[wadearnold]

Motivation:
Multiple ACH Record Formats require ABA RTN (Routing Transit Number)) commonly referred to as a Routing Number or MICR number for sending and receiving funds.

The ACH record format specification for a routing number is slightly different in each record type.

• FileHeader requires 10 digits with a zero left padding in the tenth digit. (bTTTTAAAAC) for Immediate Origin and Immediate Destination
• Entry Details require 8 digits (TTTTAAAA) as the Receiving DFI Identification and 1 digit (C) as the Check Digit.
• ADV Entry Detail Records require 9 digits (TTTTAAAAC) as Advice Routing Number and 8 digits (TTTTAAAA) as Routing Number of ACH Operator.
• Addenda Record(Returns, dishonored Returns, contested dishonored Returns, COR, refused COR) require 8 digits (TTTTAAAA) as the Original Receiving DFI Identification
• Company/Batch Header requires 8 digits (TTTTAAAA) as the Originating DFI Identification.
  This proposal is to normalize each of Get/Set functions across all record types. Allowing a consistent API for populating the ACH record. Additionally, when consumers are asked for there routing number, lower left corner of a check, it is this ABA RTN format that they will supply.

The new data type will consistently be as follows:

• A string of exactly 9 characters
• Consisting of numbers [0-9]
• The number is of the form XXXXYYYYC where XXXX is Federal Reserve Routing Symbol, YYYY is ABA Institution Identifier, and C is the Check Digit

Impact:
This will be a breaking change to the current API and documentation. Development should be on a .2 branch of the library. In many cases, functions require an int and will now require a string.

Implementation:
Where possible the RTN number will be exported rather than the underlying NACHA field specification. The library will convert, format, and validate the inputted RTN into the expected field level values for the record type.

Function calls should handle strings of length 8,9,10 where possible:

• 8 digits(TTTTAAAA)
• 9 digits (TTTTAAAAC) * expected value
• 10 digits (bTTTTAAAAC)

[chris-griffin]

Not much utility, but for what it is worth, the first two digits of the nine digit RTN must be in the ranges 00 through 12, 21 through 32, 61 through 72, or 80.

[wadearnold]

@chris-griffin I wouldn't have added that to the validator but will. We're trying to make the API language interface so that they can just send an RTN and we will handle the rest. Appreciate you chiming in!