No, not practically anyway. A finite state machine normally only remembers one piece of data: its current state.
A typical application of an FSM is lexing or parsing. For example, when we're doing lexing, it's (normally) fairly easy to encode the actions for every possible input in terms of a current state, and the value of the input.
For example, we might have a NUMBER state in which we're reading the digits of a number. If the next character we read is a digit, we stay in the NUMBER state. If it's a space or tab, we'd return the digits and then progress to some WHITE_SPACE state, or something on that order.
Now, it's certainly true that in a typical FSM (especially one that's implemented in software) we end up with bits and pieces that technically don't quite fit an FSM mixed in with the FSM itself. For example, when we're reading digits of a number, you're frequently going to save the position of the first digit, so when you get to the end you can easily compute the value of the number.
The FSM itself, has some limitations -- it has no counting mechanism. Consider, for example, a language that used "/" to start a comment and "/" to end a comment. Its lexer would probably have a COMMENT state that it entered when it saw a '/' token. It has no way at this point (short of adding another state like COMMENT2) to detect another "/" and realize that it's dealing with a nested comment. Rather, in the comment state, it'll recognize
*/ as telling it to leave the comment state, and anything else leaves it in the comment state.
As mentioned, you certainly could include a COMMENT2 state for a nested comment -- and in that, a COMMENT3 state, and so on. At some point, however, you're going to get sick of adding more states, and that will determine the maximum nesting depth you allow for comments. With some other form of parser (i.e., not a pure state machine, but something that has some memory to let it count) you can just track your nesting depth directly, so you stay in the COMMENT state until you reach a close comment token that balances up the first one, so your counter goes back to 0 and you leave the COMMENT state.
As I said, however, when you add a counter like that, what you have is no longer truly an FSM. At the same time, it is actually pretty close -- specifically, close enough that you can simulate the counter by just adding more states.
In a typical case, however, when somebody talks about implementing an FSM in software, they'll keep it reasonably "pure". In particular, the software will react to the current input based only upon the current state, and the value of the input itself. If the reaction depends on much of anything else, they usually won't call it a state machine (at least if they know what they're talking about).