- Trade representations in CSV or FpML often have issues with stubs.
- FpML validation rule IRD12 has simple alternative for a wide range of cases.
- A form of FpML IRD12 can be represented in XPath for a wide range of cases.
During proof-of-concept trials we are often asked to load up a prospects portfolio; either a CSV file from a vendor or in-house system, or even better a zip of FpML files. Regardless of the format, there can often be problems with the data, either missing data or inconsistent data. To help with diagnosing the problems we have added a trade validation function to our Clarus Microservices.
An example of use in Python
Using the Clarus python module, a simple one line call is enough to validate an FpML trade.
import clarus
print( clarus.trade.validate(trades=clarus.read('myFpmlExample.xml')) )
This code produces the following output.
Status ID Line Rule Message FAIL 12345 -1 FpMLRule.IRD-12 Payer=#partyA. Cannot increment from firstRegularStart 2018-03-20 to lastRegularEnd 2068-08-20 at frequency 6M rollConvention 20
FpML IRD-12
A common case that systems have difficulty with is the handling of stubs on swaps, either not exporting enough of the detail or exporting data which is inconsistent. FpML does define, in fairly clear terms, consistency rules so that stubs are correctly specified when taking into account roll convention and calculation frequency. Yet, it is clear that some systems have not implemented an export to FpML which reliably passes the consistency checks defined by FpML, specifically Rule IRD12. It is the one consistency rule that cannot be characterised in very simple terms via XPath, it requires the generation of a sets of dates and then a check on the first and last date. To assist with implementation of the rule, FpML have a very well written document, basically pseudo-code for the implementation of the rule, so there should be no problems, but in practice there is. Let us look for something simpler that covers many cases.
FpML Rule IRD12 states that
the frequency specified in calculationPeriodFrequency must divide precisely the schedule of regular periods from the first regular period start date to the last regular period end date. This means that by stepping through the period from the start date at the specified frequency, it must be possible to reach the end date. …
How to check that this rule is satisfied? Do we really need to generate all of the intermediate dates to be sure the data is valid?
Consider a swap trade with a first regular period start date of 20th March 2018 and a last regular period end date of 20th August 2068, with a roll convention of 20 and a calculation frequency of 12M. Do we need actually need to step through the periods from start date to the end date to be sure of IRD12? No. Since the calculation frequency is 12M, it is obvious that there is no hope of stepping from 20th March 2018 to 20th August 2068 at a frequency of 12M, the months just don’t line up.
Consider the same case, but with a calculation frequency of 6M. Do we need to step through the periods to check rule IRD12? No. Again it is almost obvious that if we start from March 2018, the last date would need to be on a March or a September, or if we step backwards (as might be more natural) from August 2068, only the months of February or August will do, since our calculation frequency is 6M.
Finally, consider the same case, but with a calculation frequency of 3M. There are more dates, but again it is almost immediately obvious that IRD12 will fail. If one steps back, the only valid months are February, May, August, November. It is obvious, we do not need to generate all of the dates to be certain.
To generalise our observation, suppose we denote the first regular period start date by [y1, m1, d1], where y1 is the year of the date, m1 is the month of the date and d1 is the day of the date and similarly we denote the last regular period start date by [y2, m2, d2]. Then for the case of a monthly calculation frequency and roll conventions that merely specify the day of the month, such as (1, 2, 3,…, 30, EOM, IMM, IMMCAD, IMMAUD, IMMNZD)
IRD12 definitely fails when, mod(m1, n) != mod(m2, n),
where n is the number of months in the calculation frequency (typically 1, 3, 6, 12). Moreover, since the roll conventions we considered merely adjust the day within the month, if mod(m1, n) = mod(m2, n) then IRD12 is satisfied, provided both dates satisfy the roll convention. Whilst this appears technical in nature, it just formalises our instinctive and obvious observations that the months ‘just don’t line up’ in the examples above.
The comment associated with IRD12 says that XPath is not possible. Whilst that is true for the full general case, we can certainly check IRD12 for a good few cases without much effort, we only need the mod(,) function often denoted by the percentage sign, %, in programming languages. I have not used XPath, however it certainly appears to support the modulus operator, so those who rely upon XPath alone to validate FpML trades have a simple way to catch IRD12 failures for a wide range of cases. I have not looked at the roll convention day-of-the-week, simply because I don’t encounter such trades very often. The roll convention of NONE is a convention which really does require the full generation of the dates, although a shorter version that simply checks d1=d2 when d1<=28 or d2<=28 may still be useful to catch many cases when the calculation frequency is monthly.