monorepo/LCU.API.Internal.OnlineLoanApp/CRIF.ACTion/Documentation/CRIF API Risks and Issues.md

CRIF API Risks and Issues

Some of this content is copied from NVISIA's API Risk Analysis document.

Important Considerations

• The API WSDLs (description files) point to non-secure HTTP endpoint URLs. These URLs should not be used.
• CRIF can enable IP address whitelisting upon request. NVISIA recommends that this be used, and it is currently enabled in the production environment.
• The XML any-typed body fields mean that changes on CRIF's end cannot be automatically detected or updated via the API WSDL. Maintaining data models may require a large amount of manual effort as the vendor was unfamiliar with any code generation process.
• CRIF states that the “ACTion API only supports the Transactions, Elements, and Fields as described in [the documentation]”. Certain transactions or fields desired by Landmark Credit Union may not be available.
• Documentation is spread throughout a few places, including CRIF’s in-progress data mapping document. Documentation has been missing or wrong in some cases.

Known Issues

• The XML formatting of the UAT system’s error responses is different than described in CRIF’s documentation.
• State abbreviations in addresses are validated against StateEnum in commonSchema.xsd and must also match a listing in the v_RptGeoCode_v001 table. As of September 2018 FM and MH are listed in the XSD but are not listed in the database. Addresses submitted with either of those values results in a foreign key SQL error from CRIF. FM and MH are also available in the ACTion web interface and will prevent the loan from being saved.
• The CRIF update deployed to Landmark's UAT environment around July 23rd contains a bug that prevents most, if not all, applications from being saved due to an 'IX_PartyRelationship_ParentPartyID_BeginDate_ChildPartyID_ChildBeginDate_RelationshipTypeID' SQL error. CRIF has a fix that has now been applied to the UAT and Production environments.
• Not all custom field types can be written to, and the documentation is wrong in this regard. Product-level and borrower-level fields are supported. Application-level and collateral-level fields are not currently supported.
• The UAT environment does not accept all of the API calls defined in CRIF's reference XSDs (addIndividualApplicant, for example, is not supported).
• Many of the calls used to edit existing loans do not work as expected even when accepted by the server:
  • addApplicant calls appear to prevent the updated loan from being opened in the ACTion web application as an IIS error screen appears instead.
  • addIndividual calls do not save martial status or anything sent in the trades element.
  • updateApp does not appear to be able to save relationship data (that is, indicating that two parties are married to each other), though the call is accepted by the server.
  • updateApp calls adding individuals to a loan results in a SQL error response from the API server

Other Risks

• The CRIF API server does respond over HTTP (port 80) but appears to only respond with system data over HTTPS.
• CRIF has informed us that the API layout and definition is generally stable from a development standpoint but there will be changes made as the underlying data models for the core applications change over time. These changes do not seem to correlate to ACTion version numbers.
• Mismatches between API-required fields, business-required fields, CRIF-required fields, and documented fields can complicate data submission.
• Custom fields, such as channels (that is, LCU branches), may have different IDs in each environment/version. The UAT environment may especially change over time when it is refreshed from the production environment.
• Submitting a loan that references a disabled custom field will result in a loan that cannot be view in the ACTion web application.