It's actually not a problem with using BigInts, but a problem of *not* using BigInts: The wrong result is a side-effect of using Reals instead of BigInts to carry out the calculation. The simple work-around is to use BigInts.
Do this by converting one or both of your numbers to BigInt, before multiplying. To convert a number on the stack to a BigInt, go to the Integer menu and tap ->big. A "big" badge will indicate the BigInt type.
What you're running into here with Reals, is the size limit of integers that can be accurately represented. In ND1, Reals can represent integers up to 2^53-1.
In practice, this means integers beyond 15 digits are not safe. (Some may be accurately represented, others not.)
If you type in a >15 digits integer on the edit line, it will be automatically made a BigInt (complete with badge), but there's no automatic promotion of arguments to BigInts for results which exceeds what a Real can represent. (Adding such a check would slow down operations on Reals tremendously.)
When multiplying these two numbers, most calculators will give you the result in exponential presentation, with *fewer* accurate digits--but at least the shown digits are correct. This is important, and I will look into doing this in ND1, too, while keeping all but the unsafe digits for a longer, better mantissa.
Thank you for reporting.
P.S. Read this if you're an HP 49, 50g user:
ND1 breaks from type conventions in HP 49, 50g in two ways:
a) lists, and all kinds of vectors (symbolic, complex, real) are unified into one array type
b) numbers entered without a period are Reals, and not BigInts
(So, if you expected your numbers to be BigInts, know that they weren't. ND1 breaks with 49, 50g compatibility in this respect because this particular convention caused confusion and led to inefficient RPL code being written (when people forget to type the period).)