I agree. It's still going on. I have complained to the Rogers Bank Ombudsman. No resolution yet.
Hey guys, update - at some point in November 2020, Rogers Bank fixed the incorrect positive/negatives on their ofx downloads. I haven't reviewed the files in detail to see if anything else was fixed.
I only noticed because when I did my yearly reconciliation, some values were super low because November/December purchases were counting as credits. (In my monthly reports, I didn't notice because there were no "conflicting" transactions)
I'm not sure if I'll just have to reverse the positive/negative on my custom import routine or if I can revert to using the standard OFX import code. Fingers crossed!
OK HALLELUJAH: they've fixed the OFX (at least as far as I can tell)... I was able to use my standard import code to import the transactions.
transaction ID is there, date formats are respected, debits and credits are properly signed, account ID and institution ID are there.
Lol how many years was this? But I'm grateful to retire the custom import routine. Also, transaction ID will make duplicate detection possible. Only thing missing now is "download transactions since last download" functionality, which should be possible since the transaction IDs are there now. But I can manage without it.
Since 2021-01-20, MS Money rejects the OFX downloads saying that the file is corrupt. I have inspected the OFX file but do not see what the issue is. Is anyone else having this issue?
Also, there is another bug still in the code where they do not use the escape sequence for the & character when it appears in a payee name. It should use the escape sequence & . For this, I just edit the file using Notepad to insert the correct escape sequence. That worked until about 2021-01-20, and now MS Money rejects the file for some other unknown reason.
I finally discovered the issue with the OFX files: there are 3 non-ASCII characters at the start of the file that should not be there. In hex, the three characters are: EF BB BF . This was difficult to find since MS Notepad does not show these non-ASCII characters. I only found them by comparing the Rogers file a another institutions file using a the File Compare (FC) utility in windows. Rogers, please repair your OFX software to remove these 3 non-compliant characters. In the meantime, I have a workaround: open the file in Notepad, select "save as", and in the "encoding" box select "ANSI", instead of the original "UTF-8 with BOM". This removes the 3 non-ASCII characters.
Well done. I will pass this fix on to my contact at Rogers Bank. My understanding in talking with them is that they contract out this aspect of their business and their contractor is telling them that it's all being done according to the latest ofx standard. Personally I find that hard to accept when there is no similar problem at other financial institutions that I deal with.
My guess is that someone has gone in and monkeyed with the process, at least, with respect to the export data process and set the wrong output type. End result, the data file doesn't open when it arrives in the customers hands.
Fwiw, Notepad++ can probably help in these types of situations: https://notepad-plus-plus.org/downloads/