Object-oriented programming (OOP)

Object-oriented programming is a programming paradigm that is concerned with abstracting complexity from logic and functions into objects and classes. When speaking of object-oriented programming, we often refer to the following 4 principles:

Abstraction

Abstraction is about extracting relevant key points from somewhere. In the context of OOP, this refers to reducing complexity by extracting an object’s functionality into a more general definition that may be applicable to different objects. Internal implementations should be hidden if not relevant for the use of other objects. The function logic of an abstract class can be implemented in its derived classes.

Encapsulation

Encapsulation refers to encapsulating an object’s functionality in itself, making available only functionality that needs to be accessed by other classes. Access modifiers can be used to mark fields or functions as private, which will not allow other classes to access these.

Inheritance

Inheritance refers to one object, a sub-class, inheriting / reusing functionality from another, its parent class. This allows programmers to introduce an object hierarchy in code and considerably reduces development time. For example, we can say that a Limousine object is a subclass of a Vehicle object, therefore inheriting the drive functionality of the Vehicle object.

Polymorphism

Polymorphism refers to the idea that objects can take different forms and share functionality. For example, a Limousine is both a Limousine and a Vehicle. The vehicle may have a drive function with a default speed of 10km/h, while the Limousine class overrides this function with a speed of 100km/h.

Open Banking

The goal of open banking is to increase competition and allow small enterprises and users to access their financial data and initiate payments in a standardised format. Since open banking has become a regulatory requirement, it has truly been a revolution, allowing small enterprises to compete with big financial institutions by leveraging open banking application programming interfaces (APIs).

Even though there exists a handful of standards across the globe that specify how financial institutions in certain regions should supply their data via API endpoints, such as Berlingroup for mainly German institutions, STET for institutions in France and PolishAPI standard for Polish institutions, and while the Open Banking UK standard is doing a great job in doing so in the UK, within these standards institutions still differ in their implementations. This makes it difficult for enterprises to integrate with different open banking APIs, as one would have to integrate and test institutions one-by-one which can be an arduous task.

This is where Yapily comes into play, allowing users to interact with the APIs that financial institutions offer in a standardised manner (as much as possible). The goal is to have a common format for API requests and responses across open banking standards. For instance, the format of a payment initiation request for a Raiffeisen Bank in Germany will be identical (almost) to the equivalent request for Credit Mutuel in France, even though the two institutions follow different API standards. This allows Yapily clients to provide open banking functionality to their users in a standardised format.

To allow Yapily users to seamlessly interact with open banking we analyse financial institutions’ APIs to see how we can fit their specification into our existing codebase. In order to do so, we had to come up with a clever way of structuring our codebase. Java OOP has turned out to be very handy for this.

Yapily Use Case

In order to implement a structurally coherent open banking API that is both scalable and highly performant, we structure our codebase into the following architectural components.

🧂 Ingredients “Ingredients” are at the top of our architectural hierarchy and specify our overall structure of our open banking implementations. In our ingredients we specify classes that are common across recipes. No matter whether an institution is following the Open Banking UK standard or the STET standard, the overall model will remain the same. For instance, a payment converter, which converts Yapily user requests to institution requests and institution responses to Yapily user responses, is applicable for every open banking standard. Therefore, we have an interface called PaymentConverter, which defines methods for converting payment initiation requests and responses. Our PaymentConverter is abstract, meaning that only general non-specific function definitions are declared and logic is to be defined in derived classes.

🍝 Recipes We describe open banking standards as “recipes”. Ingredients are necessary for recipes. Our recipes implement and extend our ingredients, therefore inheriting whatever is defined in our ingredients. For instance we have an PaymentConverterV3 class that implements our abstract PaymentConverter. This represents our payment converter implementation for the Open Banking UK standard version 3. Here we define the logic required to implement our converter functions specific to the Open Banking UK standard. For instance, in the Open Banking UK standard the creditor’s address for payment initiation requests is specified via the CreditorPostalAddress object key, whereas in the Berlingroup standard this would be the equivalent of the creditorAddress object key.

🔌 Plugins Finally, our “plugins” are needed to define institution-specific details and implement functionality that deviates from an open banking standard. The plugin is the final piece of the puzzle needed to integrate an institution’s API into Yapily’s API and each institution requires a plugin (this may consist of just a configuration file). Our institution-specific implementations in each plugin extend our recipes. Institutions are completely independent, meaning that one institution-specific implementation does not affect another institution’s implementation. For example, while Monzo follows the Open Banking UK standard, the institution requires the localInstrument field to be set to FPS and does not support special characters in names for payment initiations. Therefore, we created a new child class PaymentConverterMonzo that extends PaymentConverterV3, our payment converter implementation for the Open Banking UK standard version 3.

While the above presents a perfect example of how we leverage object oriented programming principles to implement an institution-specific payment converter, there are many differences between institutions. This includes but is not limited to different endpoints needing to be called throughout a flow, specific headers being required by an institution, or request bodies needing to be securely signed with a certificate.

Combined with a microservices architecture, the above components allow us to create a structurally coherent codebase, which is scalable and maintainable. It also enables us to keep logical components decoupled to make it easy for developers to make changes without affecting other institution implementations.