What is a fin number

A history of account and routing numbers

A history of account and routing numbers

As bank-to-bank transactions grow in popularity, the two strings of numbers that facilitate them—bank account and routing numbers—have likewise grown in importance. (And, some might argue, vulnerability.) While bank accounts have existed since ancient Mesopotamians stored their gold, grain, and weapons in temples for safekeeping, they existed without unique identifiable numbers until very recent times—and are largely related to innovations to help process checks.

While bank account numbers might only go back several decades, their story isn’t straightforward. When we sought to track down the exact origin of bank account numbers, it proved to be a surprisingly difficult process (and an interesting exercise in what happens on those rare occasions when Google comes up short!). We talked to several professors of banking history, economics, and financial history; an American history librarian at Columbia University’s Rare Books Library, which houses the archives of the New York Clearing House; and the archivists of a few major banks. To our—and to their own—surprise, no one had a definitive answer.

“It seems the introduction of the account number varied by bank,” said Claire Twinn, an archives manager at HSBC. “It looks like HSBC introduced account numbers during the 1960s/1970s when computers were brought into the business.”

She added that HSBC’s first computer was installed in 1967, but that other UK banks may have had computerization and account numbers longer.

Nicholas Webb, an archivist at Barclays, came up with a similar theory. According to archived documents like checks, customer statements, and automation records, Webb’s best guess is that Barclays account numbers were widely introduced between 1961 and 1974, during which bank branches were being connected to the bank’s computer centers.

By the late 1960s in the United States, people were still required to visit banks in person to withdraw and deposit money, likely by providing a name associated with the account and other personal identifying information. (The United States saw its first ATM in 1969.) With computerization also came the invention of Magnetic Ink Character Recognition (MICR), which uses magnetic ink to print routing and account numbers on checks. An electronic reader deciphers these numbers to quickly and systematically sort checks for processing. It might have been these innovations in efficiency that played a role in the introduction of account numbers in the United States. Indeed, if you look at photos of checks dated from 1960 (like this one, from First National Bank, signed by legendary baseball player Ty Cobb), there are only names—no account numbers and no routing numbers. By 1965, however, checks have MICR numbers printed on them with distinct account numbers, like this one signed by boxer Rocky Marciano.

The routing number had already been around for half a century before the account number became standard. Routing numbers were introduced in 1910 by the American Bankers Association (ABA) to avoid confusion in cashing checks. Unlike bank account numbers, routing numbers aren’t unique to users; each bank has its own, publicly-known identifying routing number. Basically, the ABA wanted to avoid the possibility of checks written from Bank of America, say, getting withdrawn from American Bank (or any other institution with a similar name). At the time, the bank business was booming: By 1920, there were nearly 30,000 different banks in the United States—more than in the rest of the world combined. (Today, there are closer to 18,000—though more than 50 percent of deposits are held at the top 10 banks.) So it’s easy to see how ambiguities could arise about which bank owed you money; routing numbers were the first step in straightening that out.

The efficiency that routing and account numbers provided helped launch checks as a primary means of payment in the 1980s and ’90s. Though the usage of checks has significantly declined since then, routing numbers are still very much an important part of the banking system. They currently play a role in facilitating ACH payments, which are on the rise.

But increasing instances of fraud—as well as new technologies that secure payments—is sure to bring still further change to the system, and how account and routing numbers are used.

Unpacking the bank account, routing, debit, credit and other numbers that ultimately control how we send and receive money

Checking out: A brief history of checks

How the rise of more efficient—and secure—forms of payment has spelled checking’s decline, but not its total demise

The debt debit owes to ATMs, banks, and credit card networks in becoming America’s preferred form of payment

Welcome to P.T. SECCOM Indonesia

P.T. SECCOM Indonesia is modernistic information technology company, which emphasize in professional business relationship incorporating flexibility, fast response, and friendly helpful service. We endeavor to make the entire process of developing your company’s solution a pleasurable one.

We aim to build long term relationships with our clients, working with you through every step of developing your information technology solution. It is our ethos to offer friendly and professional service to every customer, no matter how large or small.

It is essential that your company, your customers and your information system work together in harmony, smoothly, and seamlessly, not only at a technical level but at a human level. For this reason we place special emphasis on usability and build our solutions with the end-user foremost in mind.

For more information please check our Products & Services and Portfolio pages

  • A history of the Amiga, part 8: The demo scene A history of the Amiga, part 8: The demo scene

Author’s note: The Demo Scene is the latest piece in a long-running Ars series on the history of the Amiga. The last installment in the series ran in 2008, but professional obligations for the author caused a delay. More chapters[…]

What should the sequence number of a TCP/RST packet be after a TCP/FIN

I'm troubleshooting an issue and it seems the receiver is not handling a RST packet. In this case the client sends a frame of data and then a frame with FIN set. The server responds with a couple of frames with data. This data trigger the client to send a RST. Should the sequence number of this RST be the same as the sequence number of the FIN? Or should it be increased by one, as the FIN takes one "phantom" byte?

Should the sequence number of the RST be X or X+1?

OK, a tracefile says more than a thousand words. So I stripped the tracefile and posted it on cloudshark.org

I need to determine if the client should sent the RST with a different SEQ number or the server should process the RST (which it seems not to do).

Besides that this is dependent on the FIN being inside the final data packet (piggybacked), in your case, where there seems to be no TCP data inside the client FIN, the no-data containing FIN packet counts as this one phantom byte.

So in your case the RST should have a sequence number +1 higher than inside the FIN if(!) the FIN got acked previously.

Edit on new thoughts based on cloudshark post: For what I see there let me summarize the key points:

  1. The RTT and delta compared tells me that the client should have recieved the last three frame sent by the server before the RST (frames 650-652)
  2. In frame 652 the server increments his ACK number, telling that he recieved the FIN packet from the client. And now it gets interesting:
  3. The Client sends just a RST without an ACK number being set (just 0 Bytes). That way the servers retransmission trigger kicks in because of unacknowldged data (RTO

200ms and then doubleing up -> 400, 800, 1600 . see frames 654 to end)

  • The servers stack "should" react to the clients RST in frame 653, BUT due to the sequence number being 894 and the server having ACKed 895 this RST is ouf of the servers recieve window (you also see that it doesn't trigger a DUP Ack. ) so my strong suggestion is that the server ignores the RST
  • Actually I would expect the servers stack behaviour to be normal for preventing RST spoofing attacks in some way. He is perfectly sticking to the specs at least from my point of view

    I'm not sure if I understand you completely. Let me expand. This sequence of packets was captured at the server side. The RST in frame 4 is a response on the data in frame 2 (which acknowledges the data up to the FIN, but not including the phantom byte of the FIN).

    The client has no knowledge yet of frame 3, so it only sees that the server expects data at sequence number X (the X of frame 2), that would vote for seq=X for the RST.

    However, the client has indeed sent a FIN, which means the phantom byte should be taken into account, so seq=X+1 would be logical too.

    OK, now it gets interesting: If the client did not get frame 3 already he could in theory use X or X+1 as seq.nr. depending on the stacks way of implementing RST connection teardowns. Can you edit the scenario and insert timings and RTT? Just curious.

    Once he recieves the servers ACK for it's FIN bit having arrived at the server, the client would be forced to send X+1 as RST seq.nr.

    Landi, thanks for helping out. see the update on the Q for a link to the tracefile.

    see my comments on answer edit - too few space here ;)

    I second Landi's analysis, especially step 4 - from my point of view the RST has a SeqNo that is 1 byte to low and is probably discarded as invalid (out of receive window).

    OK. I do agree that the RST is out-of-window and therefor is not accepted by the server. However, looking at it some more, I think the seq with which the client was sending it was also right. It responded to the frame with an ack with the same value.

    The reason the server retransmitted over and over again is that there is a loadbalancer in between which stopped forwarding the frames properly after seeing the first RST. If it would have forwarded the packets, there would have been a frame with the higher ack which would trigger a RST with an in-window seq.

    Understanding TCP Sequence and Acknowledgment Numbers

    If you're reading this, odds are that you're already familiar with TCP's infamous "three-way handshake," or "SYN, SYN/ACK, ACK." Unfortunately, that's where TCP education ends for many networkers. Despite its age, TCP is a relatively complex protocol and well worth knowing intimately. This article aims to help you become more comfortable examining TCP sequence and acknowledgement numbers in the Wireshark packet analyzer.

    Before we start, be sure to open the example capture in Wireshark and play along.

    The example capture contains a single HTTP request to a web server, in which the client web browser requests a single image file, and the server returns an HTTP/1.1 200 (OK) response which includes the file requested. You can right-click on any of the TCP packets within this capture and select Follow TCP Stream to open the raw contents of the TCP stream in a separate window for inspection. Traffic from the client is shown in red, and traffic from the server in blue.

    What is a fin number

    TCP utilizes a number of flags, or 1-bit boolean fields, in its header to control the state of a connection. The three we're most interested in here are:

    • SYN - (Synchronize) Initiates a connection
    • FIN - (Final) Cleanly terminates a connection
    • ACK - Acknowledges received data

    As we'll see, a packet can have multiple flags set.

    Select packet #1 in Wireshark and expand the TCP layer analysis in the middle pane, and further expand the "Flags" field within the TCP header. Here we can see all of the TCP flags broken down. Note that the SYN flag is on (set to 1).

    What is a fin number

    Now do the same for packet #2. Notice that it has two flags set: ACK to acknowledge the receipt of the client's SYN packet, and SYN to indicate that the server also wishes to establish a TCP connection.

    What is a fin number

    Packet #3, from the client, has only the ACK flag set. These three packets complete the initial TCP three-way handshake.

    Sequence and Acknowledgment Numbers

    The client on either side of a TCP session maintains a 32-bit sequence number it uses to keep track of how much data it has sent. This sequence number is included on each transmitted packet, and acknowledged by the opposite host as an acknowledgement number to inform the sending host that the transmitted data was received successfully.

    When a host initiates a TCP session, its initial sequence number is effectively random; it may be any value between 0 and 4,294,967,295, inclusive. However, protocol analyzers like Wireshark will typically display relative sequence and acknowledgement numbers in place of the actual values. These numbers are relative to the initial sequence number of that stream. This is handy, as it is much easier to keep track of relatively small, predictable numbers rather than the actual numbers sent on the wire.

    For example, the initial relative sequence number shown in packet #1 is 0 (naturally), while the ASCII decode in the third pane shows that the actual sequence number is 0xf61c6cbe, or 4129057982 decimal.

    What is a fin number

    The display of relative sequence numbers can optionally be disabled by navigating to Edit > Preferences. and un-checking Relative sequence numbers and window scaling under TCP protocol preferences. However, be aware that the remainder of this article will reference relative sequence and acknowledgement numbers only.

    To better understand how sequence and acknowledgement numbers are used throughout the duration of a TCP session, we can utilize Wireshark's built-in flow graphing ability. Navigate to Statistics > Flow Graph. , select TCP flow and click OK. Wireshark automatically builds a graphical summary of the TCP flow.

    What is a fin number

    Each row represents a single TCP packet. The left column indicates the direction of the packet, TCP ports, segment length, and the flag(s) set. The column at right lists the relative sequence and acknowledgement numbers in decimal. Selecting a row in this column also highlights the corresponding packet in the main window.

    We can use this flow graph to better understand how sequence and acknowledgement numbers work.

    Each side of a TCP session starts out with a (relative) sequence number of zero. Likewise, the acknowledgement number is also zero, as there is not yet a complementary side of the conversation to acknowledge.

    (Note: The version of Wireshark used for this demonstration, 1.2.7, shows the acknowledgement number as an apparently random number. This believed to be a software bug; the initial acknowledgement number of a session should always be zero, as you can see from inspecting the hex dump of the packet.)

    The server responds to the client with a sequence number of zero, as this is its first packet in this TCP session, and a relative acknowledgement number of 1. The acknowledgement number is set to 1 to indicate the receipt of the client's SYN flag in packet #1.

    Notice that the acknowledgement number has been increased by 1 although no payload data has yet been sent by the client. This is because the presence of the SYN or FIN flag in a received packet triggers an increase of 1 in the sequence. (This does not interfere with the accounting of payload data, because packets with the SYN or FIN flag set do not carry a payload.)

    Like in packet #2, the client responds to the server's sequence number of zero with an acknowledgement number of 1. The client includes its own sequence number of 1 (incremented from zero because of the SYN).

    At this point, the sequence number for both hosts is 1. This initial increment of 1 on both hosts' sequence numbers occurs during the establishment of all TCP sessions.

    This is the first packet in the stream which carries an actual payload (specifically, the client's HTTP request). The sequence number is left at 1, since no data has been transmitted since the last packet in this stream. The acknowledgement number is also left at 1, since no data has been received from the server, either.

    Note that this packet's payload is 725 bytes in length.

    This packet is sent by the server solely to acknowledge the data sent by the client in packet #4 while upper layers process the HTTP request. Notice that the acknowledgement number has increased by 725 (the length of the payload in packet #4) to 726; e.g., "I have received 726 bytes so far." The server's sequence number remains at 1.

    This packet marks the beginning of the server's HTTP response. Its sequence number is still 1, since none of its packets prior to this one have carried a payload. This packet carries a payload of 1448 bytes.

    The sequence number of the client has been increased to 726 because of the last packet it sent. Having received 1448 bytes of data from the server, the client increases its acknowledgement number from 1 to 1449.

    For the majority of the capture, we will see this cycle repeat. The client's sequence number will remain steady at 726, because it has no data to transmit beyond the initial 725 byte request. The server's sequence number, in contrast, continues to grow as it sends more segments of the HTTP response.

    After acknowledging the last segment of data from the server, the client processes the HTTP response as a whole and decides no further communication is needed. Packet #38 is sent by the client with the FIN flag set. Its acknowledgement number remains the same as in the prior packet (#37).

    The server acknowledges the client's desire to terminate the connection by increasing the acknowledgement number by one (similar to what was done in packet #2 to acknowledge the SYN flag) and setting the FIN flag as well.

    The client sends its final sequence number of 727, and acknowledges the server's FIN packet by incrementing the acknowledgement number by 1 to 22952.

    At this point, both hosts have terminated the session and can release the software resources dedicated to its maintenance.

    Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

    Fun fact: the 3-way hanshake can be in fact a four way handshake - see here (although I don't believe that it is implemented like that anywhere):

    Great stuff Jeremy! Excellent explanation of TCP operation PLUS how to use Wireshark features to examine and learn about how a protocol works. Expect a flood of hits from my students!

    When I studied TCP first, I was thought that ack no. is the next byte receiver is expecting. i.e if ack no. is 726 that means, receiver received 725 bytes of data and sender can send data starting from 726th byte.

    So to me this sentence doesn't make much sense:

    "Notice that the acknowledgment number has been increased by 1 although no payload data has yet been sent by the client. This is because the presence of the SYN or FIN flag in a received packet triggers an increase of 1 in the sequence."

    As it seems to me that is is expecting data stream starting from byte 1. So Ack no. is not increased.

    Though the meaning is same.

    PS: Thank you for the demo of ability of wireshark. I still don't know much abt this tool.

    @Mimo: In this instance, as is typical with network protocols in general, our counter is zero-indexed; the first byte is byte 0, not byte 1. the SYN flag increases the counter by one to 1, which is actually the second possible value.

    Hope that helps.

    Mimo, you are correct. Do a search on google for TCP phantom byte and that will explain why there is an increment of 1 in the setup and teardown processes.

    Also check out Laura Chappells WireShark training, good stuff.

    Note. During the TCP startup and teardown sequence, a "phantom byte" causes the sequence number and acknowledgment number fields to increment by 1 even though no data is exchanged. This phantom byte can be confusing when you have just learned that the sequence number field increments only when data is sent.

    Great post! I've just recently started down the road to CCNA having always been interested in networking. I've used wireshark in the past for very basic troubleshooting, but this is a nice deep (comparitivley speaking!) look at TCP.

    One question: packet 36 contains a PSH or push flag. What is this in relation to the HTTP stream?

    Thank you yohan900 and stretch for the information!!

    If the PUSH bit set, data will be delivered up to the application right away, but the ack may still be delayed.

    Hope this helps.

    What a bit of luck. I have a second-stage telephone interview today and one of the subjects I will be tested on is TCP. The first interview covered it in a little detail (3-way handshake / sliding window) but this one today will delve further into it. This will help enormously - thank you very much Jeremy.

    Hi Jeremy, Nice Article. Thx for posting. If you get a chance can you continue on in this series and dive deeper into TCP with regards to the various algorithms like slow start and other concepts like windowing, congestion control, PAWS, Reno, SACKs etc. Tx

    It would have been much better to call this a "Three-step handshake" or "Three-phase handshake". To me, "Three-way handshake" implies that here are three different parties shaking hands when in fact it is a method that requires three steps for two parties to communicate.

    Just an observation . .

    Succinct explanation. Helped straighten this out in my head.

    great article , thanks ;)

    November 20, 2010 at 6:39 p.m. UTC

    Hi, So if client is sending a data over different TCP segments the acknowledge number on client side will not increase untill all the data has been sent over.

    I have a client which sends data to server and when I capture it I see the data is not in single IP datagram but I see that the whole data sent to server spans over multiple TCP segments and in Two IP datagrams.

    My questions is if I need to collect all the data sent by client to server how do I reassemble them at TCP lever. I am capturing IP packets which encapsulates TCP.

    December 9, 2010 at 12:34 p.m. UTC

    This is good stuff, but why didn't u talk about packet#36 and packet#37? If those are also added to this article, then this will be more useful for beginners.

    Like this post? Please share to your friends: