@ Work look at the OP's application and hardware,
Yes, while it's true that the M1 doesn't necessarily care what the FC in the field in relation to a credential as that is another data line in the user function, but it still must always be known in order for the M1 to function and action the input as a valid code. In the OP's case, using a keypad outside to send a PIN to the M1....he needs to know that FC always, because the reader is not going to allow him to dump the FC, credential and PIN into the M1 and get a valid "read" the intelligence just isn't there in the M1.
To get a reader to work on the M1, the data must present to the panel just like a standard W26 card with all the values known!
In the case of a KAM, it's not really a big deal if you stick with the same FC and credential type (and not getting into the argument that only having 255 FC's and 65,535 credentials is not secure). Personally, while the Elk (Ness) readers are nice, I've commonly stuck with HID readers and compatible credentials....far easier to get replacements and varieties out in the world.
And while off topic, 26 bit weigand is not a "type" or standard but a presentation of the data to the host system. I've had plenty of off the wall systems where the parity bits were swapped or the FC or credential was slightly tweaked from a "standard" W26 format but still passed through normal W26 readers and the decoding was done via the software and/or head end. Part of a way to lock a customer in for the "nationals"....and the reason why us integrators have systems that can drop or hold the FC and action it in many locations, in addition to CHUID's.