How does HSBC's "Secure Key" actually work?
There are two standard ways to build such a device:
Time-based. The device has a secret key K (known only to the device and to your bank). When you press the button, The device computes F(K, T) (where T is the current time) and outputs it as a 6-digit code.
Your bank, which also knows K, can compute the same function. To deal with the fact that the clocks might not be perfectly synchronized, the bank will compute a range of values and test whether the 6-digit code you provide falls anywhere in that range. In other words, the bank might compute F(K, T-2), F(K, T-1), F(K, T), F(K, T+1), F(K, T+2), and if the code you provide matches any of those 5 values, the bank accepts your login.
I suspect this is not how your device works, since your device always gives you a different value every time you press the button.
Sequence-based. The device has a secret key K (known only to the device and to your bank). It also contains a counter C, which counts how many times you have pressed the button so far. C is stored in non-volatile memory on your device. When you press the button, the device increments C, computes F(K, C), and outputs it as a 6-digit code. This ensures that you get a different code every time.
The bank also tracks the current value of the counter for your device, and uses this to recognize whether the 6-digit code you provided is valid. Often, the bank will test a window of values. For instance, if the last counter value it saw was C, then the bank might compute F(K, C+1), F(K, C+2), F(K, C+3), F(K, C+4) and accept your 6-digit code if it matches any of those four possibilities. This helps ensure that if you press the button once and then don't send it to the bank, you can still log on (you aren't locked out forevermore). In some schemes, if there is a gap in codes (e.g., because you pressed the button a few times and then didn't send the code to the bank), you will need to enter two consecutive valid codes before the bank will log you on.
Based upon what you've told us, I would hypothesize that your device is probably using the sequence-based approach.
If you want an 'open' explanation of how the One-Time-Password is derived you can read about the Oath standard and the specification for the algorithm here, https://openauthentication.org/specifications-technical-resources/. The Vasco/Digipass product supports this specification, and it may be used by your token in this case, however they do support other OTP generation algorithms.
Typically the serial number of the token is maintained as a record in the authentication server database, and the serial number is assigned to a username. The serial number is also matched to a 'seed' value, which when combined through the algorithm with the time/sequence value derives the OTP.
Also, you were able to punch in a PIN over and over and be authenticated because the authentication server will allow for a couple of minutes of clock drift. The token you have has a clock built in to generate the time based component. The server generates values for a range of time. It then can see which code you submit, and write a drift value to your record. Some systems will have a 'next-tokencode' mode, which is used if the clocks drift too far apart. The system will ask you to submit two values and see if they are correct and in the proper order, over a larger 'range' of time. If the values are correct the authentication server can write the clock drift value to the record.
I think this question lends itself to a very high level overview of how multi-factor authentication (MFA) works. Of course, we have to skim over lots and lots of technical detail.
In short, here is what happens:
The bank programs the token with a unique encryption key. (In this case your Digipass token is made by Vasco, but there are many other companies that make similar tokens, which are "something you have" with regards to multiple factor authentication).
The token will generate a series of characters that are derived from the encryption key, current time, and (optionally) other various factors.
Since the bank knows the (unique) encryption key, and all other other factors that the token uses, they can reverse-engineer the input to find out who "owns" that token. If the owner of the token matches the owner of the bank account that is being logged-in to, then the login is authentic.
There are many variations on this central theme, but in general they always involve "something you have" (a physical token, or a smartphone app), a secret key stored within the token, and a mathematical algorithm to produce the output.
Often, time is a critical factor in generating the output. Depending on the algorithm, the output may be different every single time (in your case), or it may only vary occasionally (e.g. Every hour).