JamesMBligh
commented
8 months ago Awesome. Thanks Shane. Couple of questions...
- Is there a specific format for LIXICode?
- For LIXIVersion, LIXICustomerVersion and API Version: is there a specific format for the fields or should we just do them as string?
- It may be good to include a mapping of CDR Product ID to LIXI ProductCode. Does that make sense?
- What is the best way to refer the client to Schematron? Would a Schematron URI suffice?
shanerigby
Data in the getOriginationScheme Response
What is required to uniquely identify a 'scheme' in this getOriginationScheme API? The following information might be useful in the context of LIXI2.
Recipient LIXICode
LIXI has maintained a list of participants in the ecosystem for over 20 years, each being assigned a LIXICode. These LIXICodes are required to be specified within the body of each LIXI2 lodgement for both the sender and recipient (the Action Service Provider in the context of CDR).
LIXIVersion
In LIXI2, each version of the published LIXI2 Schema is defined by a fixed value in the schema that specifies the required LIXIVersion that needs to be included within the body of the message.
LIXICustomVersion
In addition, there is a similar item for the LIXICustomVersion. Licensees can create custom versions that are more restrictive than the published standard - and licensees manage their versioning of this using this LIXICustomVersion item. LIXI2 Licensees can use as many custom versions as they need for different purposes - different schemas for different product families, product packages, products, or even to specify the required data within successive stages within the origination process.
ProductCode
Each credit or deposit product within the application can be assigned a code maintained by the product provider (the ProductCode).
API Version
In the LIXI2 ecosystem, a single swagger specification API is often used to support the submission of messages conforming to one of many LIXI2 schemas, and can allow either a JSON or XML message body. This also allows the underlying supported schemas to evolve independently of the mechanics of the submission (ie the Open API Specification).
Summary
In the context of the experiment, the schemeId within the Action Service Provider's 'Get Origination Scheme' endpoint must provide sufficient information to retrieve (via some other mechanism if not within the CDR) the actual schema definitions that are suitable for submissions in the body of the applyForAccount API. Whilst the schemeID might be sufficient it would likely be more useful to include the combinations of LIXIVersion, ProductCode and LIXICustomVersion that can be used.
Either way, the question remains as to where must the Action Service Provider obtain the exact schemas and associated rules that define a complete and internally consistent submission. Some lenders are starting to implement Schematron definitions to better articulate the internal consistency requirements within a submission. These Schematron definitions provide the user of the API with much more granular requirements around the creation of a submission that will be successfully processed that can be (and should be) evaluated prior to submission. In my opinion there is no reason to preclude such a mechanism at this stage.