Here’s how you standardize all external vendor data formats using the Lending Rules.

To verify a person’s existence and credit history, it is enough to know their name, date of birth, and residential address. For this purpose, it may be enough to get the user’s selfie and an identity document.

Different web protocols can be used to interact with third-party providers. These include SOAP, REST, XML-RPS and others. As well, different types of data access protocols – such as WASP, API tokens, and others – can be implemented. Third-party providers typically return data in a format that differs from the format needed for the project, so you need to standardize these formats to enable the business layer to process it.

For example, the key SPI46 from the third-party vendor stands for the user’s taxable income for the last 12 months. To the third-API component, the strange name is converted to grossannualincome field, with a float type. Even more, the third-API gateway component returns this data in JSON, but initially was received from the third-party vendor in XML format.

If the one data provider changes to another, the business logic should not be affected. The function of checking the taxable income of the user must remain the same as it was with the previous provider. In this case, though, the data provider changes, but the third-API gateway service itself retains the same interface. It receives and returns the same data as before. The field in which the new data provider provides information about a person’s income for the last year is called PersonPreviousYearIncome, but the third-party API itself still gives the information in the field grossannualincome, and still in JSON.