Derivatives allow many degrees of freedom, and consequently FpML allows a wide variety of structures. Not all of these structures will make sense from a business perspective. Prior to processing an FpML message from an uncontrolled source, it will be necessary to validate that it can be processed by the receiving firm or system. GemCheck does these checks and provides information that can be used to efficiently guide processing.

The validation suite will peform validations at least consistent with the validation rules and language specified within the FpML validation working group. However, the emphasis of the suite will be to provide simple configuration of the key variable items that firms will require to validate FpML trades for their processing requirements, and implement standard consistency rules as simple, efficient black boxes, that can easily and efficiently be integrated into FpML trade processing.

• Validate internal document consistency, e.g.
• Validate date consistency
• Validate element consistency (i.e. that optional elements that are required to be present for particular configuration are in fact present)
• Validate the reference ids are present and unique
• Validate that schemes are defined explicitly or by default
• FpML Version checking/promotion
• Validate reference data, e.g.
• Validate schemes and scheme values … verify that they meet internal processing requirements
• Validate party identifiers
• Validate that business policies are respected, e.g.
• Valid product types and features
• Valid currencies and indexes.
• Term/Maturity date within limits.
• Notional principal within limits
• Categorize instruments for processing, e.g
• Single currency vs cross currency swaps
• Swaps vs. options
• IR vs. FX
• High level business rules/policies contained in simple, high-level XML configuration files
• Callable from GemSync server
• Capture validation and categorization information in XML form in a way usable by the GemSync server to direct processing. (e.g. route to a different destination based on category or validation status.)
• Feature list/priority subject to change based on member input.

A large set of sample message and validation configuration files and known exceptions will be created, and the validation software will be run through an automated regression testing process based on these. Whenever changes (including fixes to newly discovered defects as well as enhancements) are made to the functionality of the suite, new test cases will be created and added to the testing suite to verify the accuracy of the changes. The validation suite will also be compared with results obtained by different implementations of the standard FpML rules language where practical.

• Validating deal feeds from external parties
• Data scrubbing existing databases
• Aiding developers developing deal feeds from existing or new systems
• Compliance checking, either pre-trade or on existing portfolios, e.g. in deal assignments.
• Sanity checking deal feeds into downstream systems.

• Currently in planning
• We are participating in the FpML validation working group.