SN CDS - trade model about strata HOT 7 CLOSED

Following FpML 5.7 schema as much as possible. Modelling only the data needed to generate a CDSAnalytic object as the target (at that point, together with market data, we should be able to price).

Using jaxb to generate FpML java classes and parse example trades/securities that they provide. My Strata trade model should closely match the FpML classes and make a mapper implementation very straightforward.

This generated jaxb/fpml code can be stashed or housed on a branch until the appropriate time to integrate into Strata, but it is an helpful intermediate tool for development on my branch.

from strata.

Using Sesame Examples RemoteCreditTest as a first proof point. I should be able to prove that I can generate the exact same CDSAnalytic using the new trade model.
Will work with James to expand those test cases.

from strata.

Remember to use all the classes in strata-basics for date/schedule/holidays, as per Swap and Fra. In particular PeriodicSchedule. Most of the concepts there map fairly well onto FpML concepts, though sometimes with different names.

from strata.

Approach has been:

1. to make sure our trade model maps as closely to FpML 5.7 (pretrade view) schema as possible. (http://www.fpml.org/spec/index.html). We will only need a subset of the data from the FpML XML for pricing, but keeping in sync with the schema will make FpML import trivial and ensure that we are not deviating from market standards.
2. Target the ISDA standard model (http://www.cdsmodel.com/cdsmodel/assets/cds-model/docs/c-code%20Key%20Functions-v1.pdf) to understand exactly what data is required for feeding this model. Certainly to support standard single name and index CDS for margining, providing the necessary inputs to this model is the proof point that we are targeting.

We are not concerned with legacy (long form CDS trades) for the moment as they are not always supported by the standard ISDA model, would not be relevant to margining, and modeling the additional information will just cloud things up for standard clearing eligible CDS trades. But the FpML trade modeling is flexible enough to support them, so it should not be difficult to extend out business objects if support for these legacy products is required later.

As mentioned, the trade model will have a builder allowing us to model everything required to feed the ISDA standard model. But some of what goes into that model are established market conventions (for instance, the standard 100bps or 500bps coupons in North America) or the fact that no holiday calendar is needed except for JPY. We plan to provide a API wrapper around the builders that encode these market conventions so that creating a standard CDS trade requires minimal boilerplate.

For instance:

    CreditDefaultSwap fordSingleName =
    CreditDefaultSwaps.northAmericanSingleName100bps5Y(
        10_000_000D,
        LocalDate.of(2015, 6, 1),
        "Ford Motor Company",
        "3H98A7",
        SeniorityLevel.SeniorUnSec
    );

If these helper wrappers are not flexible enough, users can always use the underlying builder directly.

Using the builder directly would involved specifying the day count, calendar, roll convention, etc.

from strata.

Just to note that we package up conventions as implementations of the Convention interface. This allows them to be stored and passed about if necessary. See also the Template interface and implementations.

from strata.

This is supported (for par rate shifts on the curve inputs) in the topic/credit branch

from strata.

Fixed by #341

from strata.