Having examined your Insurance Summary.txt file, it is clear that the dates there have been stored there as text strings in a variety of formats, but all with the day preceding the month. Some even lack the year, which is in an adjoining field. And some are seriously corrupted (fields NIN2Z2, DBT2Z2, & NIN3Z2). Because the dates have been stored that way, they violate the OLE DB requirement for dates to be stored in the US-date format. Hence, when the mailmerge attempts to interpret the ones expressed in D/M/YYYY format as US dates in the M/D/YYYY format, you're getting bogus results. The only dates that would be rendered correctly in this scenario are those that are spelled out in full (e.g. field YYYCZ1, as 6th September 2018) and those where the first figure in the stored date is more than 12 (since months 13-31 don't exist).

IMHO, whoever coded your AS400 that way ought to be replaced. Dates should always be stored as such so the data are portable; any regional or other formatting should be handled as a display/print format issue.

That said, it should be possible to work around your present situation with field coding such as:
{QUOTE{SET IssDate "{IF{MERGEFIELD EFFALP \@ "d"}< 13 "{MERGEFIELD EFFALP \@ "M"}/{MERGEFIELD EFFALP \@ "d"}/" "{MERGEFIELD EFFALP \@ "d"}/{MERGEFIELD EFFALP \@ "M"}/"}{MERGEFIELD EFFAYR}"}{REF IssDate \@ "d" \* ordinal}{REF IssDate \@ "MMMM YYYY"}}

__________________
Cheers,
Paul Edstein
[Fmr MS MVP - Word]