{"id":1558,"date":"2019-10-11T18:10:12","date_gmt":"2019-10-11T15:10:12","guid":{"rendered":"https:\/\/djangostars.com\/blog\/?p=1558"},"modified":"2025-08-15T12:28:42","modified_gmt":"2025-08-15T12:28:42","slug":"3rd-party-api-fintech-mortgage-apps","status":"publish","type":"post","link":"https:\/\/djangostars.com\/blog\/3rd-party-api-fintech-mortgage-apps\/","title":{"rendered":"Implementing Third-party API Layers in Fintech Applications"},"content":{"rendered":"

Nowadays, fintech products are everywhere. They visibly or invisibly improve our lives and have made getting loans, mortgages, and other banking services easier and more accessible than ever. This industry boom has initiated a dramatic burst of new startups on the market (e.g, mortgage startups). The stakes are high, and the competition is tough. In competing for clients, companies are inventing more and more sophisticated features, making products more user-oriented, or presenting ever more attractive offers.<\/p>\n

But all these neat features won\u2019t mean a thing if the real product works slowly or is clumsy and hard to maintain. Drawing on our 10 years of experience in fintech software development services<\/a>\u00a0(with at least 5 of them spent as financial software development company), in this post we\u2019ll share our expertise on how to ensure good application performance by creating well-thought software architecture that implements third-party services via an API layer.
\n

\n
\n\n <\/div>\n
\n \"logo\"\n

\n\t\t\tDisrupt the financial market<\/u>
\nwith a strong product\t\t\t <\/h3>\n\t\t
\n Learn how<\/a>\n <\/div>\n\t\t <\/div>\n<\/div>\n<\/p>\n

Fintech Applications Primer: Why Third-party APIs are Key<\/h2>\n

A vast majority of financial applications rely on third-party data and integration of third-party data providers is important stage of the financial app development process. Third-party services provide the application with features which, if they had to be developed from scratch, might require a significant \u2014 and excessively long for some lending startups \u2014 amount of time. In particular, data received from the third-party API for the fintech app is used to process market offers, analyze the user\u2019s credit score, evaluate property, reveal fraud, or even connect the user\u2019s banking info to their profile. For example, open banking services share data to ensure quicker and easier access to financial services. In sme lending solutions<\/a>, this is a key part of the business logic, since users typically provide about 15% of the data needed for service delivery.<\/p>\n

Using common rules, third-party services are implemented in the product by simple fintech APIs integration. It\u2019s not a problem if there are just a few of them, but when the product is complemented with dozens of such services, fintech app integration and its architecture arrangement may be quite difficult. This is when the API layer can connect third-party services with the product.<\/p>\n

Now let\u2019s dig deeper into why our web development company uses a third-party API layer, how they are built, and the advantages they offer in terms of managing complex ecosystems in an elegant way.<\/p>\n

Why Use Separate Business and Data Layers in Fintech?<\/h2>\n

Let\u2019s start with the basics. Why would you even need to separate the business and data layers? By the business layer, I mean business logic. Here, I\u2019ll demonstrate solutions using an example of an online mortgage platform, but it can be applied to any fintech solution that has more than a few integrations with third-party services.<\/p>\n

Given that our example platform is directly connected to finance, we must include a lot of verifications, including fraud prevention. Only after all the checks are passed can funds be transferred to mortgage lenders. As you might guess, the data for these checks are supported by the third-party services.<\/p>\n

To make it clear, our platform consists of two integral parts \u2014\u00a0 the business one, and the data one. The first is the layer the user interacts with. The data layer is behind the business part and makes it work. It includes third-party integrations that are responsible for providing the data concerning security, fraud recognition, market offers, analysis and other vital services.<\/strong><\/p>\n

The following example will illustrate how this works in practice. A simple lending rule like minimum-age verification (that the customer isn\u2019t less than 21 years old) can be realized by the client while they are filling in their personal data, or by validating this data on the server side. But for the business layer, this rule looks like the function that initially accepts the user\u2019s age argument and results in a boolean value: whether the rule is passed or not.<\/p>\n

The lending business may include hundreds of such rules, and the major part of them strongly depends on third-party data providers. The problem is that these services provide data in different formats which may not always be recognized by the mortgage platform\u2019s business layer. As a result, received data must be converted from the external format to the internal one. For example, `Y`\/`N`<\/code> from the third-party fintech API provider must be translated into the boolean `true`\/`false`<\/code> in order to be processed by the business layer.
\n\"lending-policies-flow-API\"
\nTo create a simple verification mechanism to gauge the user\u2019s financial solvency, property quality and other lending criteria, it is necessary to work with normalized and clear data. To ensure smooth performance, where and in what format this data comes from should not be problematic for the business part. Given the fact that it\u2019s necessary to integrate numerous providers in order to receive all the data we need, there is merit in separating them in the particular component known as 3rd-API component. This component should be carried into separate services or projects that will receive info from the user and return formatted data necessary for the lending rules (for the business layer). Thus, to make the process flow smoothly and ensure that all the data will be properly formatted and properly, we separate the business rules from the process of getting data for these rules.\u00a0<\/strong><\/p>\n

Advantages of Third-party API Layer Implementation<\/h2>\n

To sum up the above, in our online mortgage platform that uses data from numerous third-party services to properly process information received from the user, we used a third API layer as a proxy between the business layer and third parties. Such an approach ensures a clear and structured service architecture that is easily understandable and manageable. Let\u2019s take a closer look at the advantages this separation provides.
\n\"advantages-of-the-3rd-api-layer-implementation\"<\/p>\n

    \n
  1. Elegant and well-thought-out software architecture<\/li>\n
  2. More complete QA coverage<\/li>\n
  3. Easy switching\/adding 3rd-party API providers for fintech apps<\/li>\n<\/ol>\n

    Elegant and well-thought-out fintech software architecture<\/h3>\n

    Well-thought-out and logically structured product architecture allows you not only to make implementations easily and effectively maintain the service. It also means that the code is easily understandable, the connections between the different components are logical, and that if the product is passed to another development team, they will be able to work with it easily. Even separate teams could work on business and third-party proxy layers. The third API component becomes an aggregated third-party provider for the business component. If you need high confidence in the customer\u2019s taxable income for a lending rule, where and how to get it is a job for a third-API component.<\/p>\n

    To be clear, paying attention to product architecture is not a \u201cmust\u201d in the development process. Sometimes it may take additional development time, and due to that may appear as an excessive effort. But spending a bit more time on architecture structuring at the pre-development stage will save much more time at the development and post-release stage, when product maintenance may require the addition of some components. Well-structured architecture allows you to do it easily and in little time. Although someone may deem a good product architecture\u00a0 a luxury in the development process, we consider it a necessity that will ensure smoothly running product.<\/strong>
    \n

    \n
    \n\n <\/div>\n
    \n \"logo\"\n

    \n\t\t\tPython & Django<\/u> development\t\t\t

    \n Your chance to enter the market faster <\/p>\n <\/h3>\n\t\t

    \n Learn more<\/a>\n <\/div>\n\t\t <\/div>\n<\/div>\n<\/p>\n

    More complete QA coverage<\/h3>\n

    By using a third API gateway, it\u2019s possible to create the most complete testing sandbox you\u2019ll ever need. Usually, to test whether the system receives and gives data properly and in the proper format, the tests cover the third-party integration from which this data is received. However, sometimes tests need to check data that a third-party API simply can\u2019t provide due to the limitations of the sandbox.<\/p>\n

    For example, let\u2019s say we have to check whether the roof of the property to be lent is not thatched. In such case, we create a mock third-party service to test an environment like that one and, with the help of the third API layer, we can easily add mock providers to ensure full test coverage. We have just switched from one property valuation provider to another, but haven\u2019t changed the business flow and logic at all.<\/p>\n

    Easy switching\/adding third-party providers<\/h3>\n

    The most practical advantage of using a third layer for APIs is that by keeping live data and mock inputs separate for testing, you can switch\/add providers without touching the business logic.<\/p>\n

    Thus, you can easily switch between several providers, depending on each separate situation, without affecting the business logic. Thanks to the third-party API layer, the business layer will receive the data in a proper format, irrespective of the type of provider. This means that for less-complex requests you may use providers with more limited volumes of data, but which are cheaper. And if only the request is too complex for a cheap provider, the system will automatically switch to a better one. This allows the system to allocate resources rationally.<\/p>\n

    How We Build the third-API Architecture<\/h2>\n

    Here\u2019s how you standardize all external vendor data formats using the Lending Rules.
    \nTo 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\u2019s selfie and an identity document.<\/p>\n

    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 \u2013 such as WASP, API tokens, and others \u2013 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.<\/p>\n

    For example, the key SPI46 from the third-party vendor stands for the user\u2019s taxable income for the last 12 months. To the third-API component, the strange name is converted to gross_annual_income 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.<\/p>\n

    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 gross_annual_income, and still in JSON.
    \n\"third-api-architecture\"
    \nThus, the third-API gateway serves as a layer for communication with the third-party providers. It is able to work with different data providers, preserves the same interface, and normalizes and recasts data to the type used internally.<\/p>\n

    Use-cases for Backend-selectors and 3rd-API Architecture<\/h2>\n

    In this section, I\u2019ll demonstrate how our software development team uses the above solution in our online mortgage platform. So, we have a third-API gateway that can communicate with third-party integrations and has a stable and fixed interface. To make it work as required, it is necessary to write a backend (provider) selector that will work with different data providers, depending on the environment.<\/p>\n

    Use case #1.<\/strong> Let\u2019s assume we have a credit rule for real estate: verify that the roof of the building is not made of straw. Given the limitations of the testing sandbox of a default real estate appraiser, it will be difficult (or even impossible, in this environment) to find such a property in London. Thus, in the test environment you can switch to another provider \u2013 for example, to the data that will be specified by the QA team for the property of interest. This type of provider can be called a \u201cmock provider\u201d. The service that is responsible for business logic receives data from the third-API gateway, runs a credit rule, and testers (QA) can make sure that the user whose property has such a roof won\u2019t be able to move further along the flow.<\/p>\n

    Use case #2.<\/strong> There are a lot of data is based on property addresses. Let\u2019s assume the customer interacts with the residential or property address input. The backend turns to the third-API gateway which, via search keywords, begins to query all of the data providers for the address search described in the application. The response of the first one is returned by a gateway to the main application, and from the backend to the client side. Thus, for the main application, it makes no difference what kind of integration the address details have been obtained from. The application just needs to know those details, and that’s it.
    \n\"Financial-APIs<\/p>\n

    Conclusion: When to Use this Approach and What to Pay Attention to<\/h2>\n

    The above solution significantly simplifies the application structure, and makes it clear and concise. To be clear, it won\u2019t be the end of the world if the architecture of your application remains messy (for some time). For example, if your aim is to make an MVP just to test your idea, a messy structure is okay. But if you\u2019re planning to release the application to the market, you\u2019d better pay attention to its architecture and structure. Otherwise, in the future it may be quite hard to scale the product or add new features to it.<\/p>\n

    Also, you should note that you need to remember to keep an up to date third-API client on the business side with third-API proxy component layers. If the field name from the business layer changes, the third-API layer should also change its API. Both the business side and third-API components should be synced with each other (if it is related to the field names).<\/p>\n

    An API layer is a savior when you\u2019re building API for a financial app that has numerous integrations with third-party services. The payer can be used in fintech and other areas where application business logic is the keystone.<\/p>\n

    If you need assistance implementing a third-party API layer for a financial app or for insurance software development<\/a>, contact the Django Stars team.

    \n
    \n

    Have an idea? Let's discuss!<\/p>\n\n \n

    \n

    <\/p>

      <\/ul><\/div>\n
      \n
      \n\n\n\n\n\n\n\n\n<\/div>\n
      \n
      \n
      \n \n Your name *\n <\/span>\n \n\n \n <\/div>\n
      \n \n Your email *\n <\/span>\n \n <\/div>\n <\/div>\n
      \n
      \n How can we help you? *<\/span>\n \n <\/div>\n <\/div>\n
      \n \n
      \ud83d\udcce Attach File<\/span>\n Formats: pdf, doc, docx, rtf, ppt, pptx.<\/span><\/div>\n <\/div>\n
      \n
      <\/svg><\/div><\/div>
      <\/svg><\/div><\/div>