BIAN Adoption at Zafin

By: Arno Hensbergen, Principal Architect, John Mason, Customer Engineering Head, Alok Sahi, Chief Architect, Shahir A. Daya, Chief Technology Officer

Introduction

This article outlines Zafin’s adoption to the BIAN framework and discusses how we utilized it to build a viable iteration of Zafin Agreements. It articulates conformance and explains divergence from the BIAN v11.0 standard. This article is the first of a series that puts our new BIAN inspired software and its APIs on display.

Zafin Agreements is a new software that bridges the gap between Enterprise Customer Data and an Enterprise Product Catalog. It provides a scalable and central system-of-reference for the full lifecycle of bank customer agreements.

What is BIAN?

“The Banking Industry Architecture Network (BIAN) is a global, not-for profit association of banks, solution providers, consultancy companies, integrators and academic partners with the shared aim of defining a semantic standard for the banking industry.

BIAN was formed in 2008 by a group of banks and solution providers. Other standards bodies, like ISO and IFX, later joined.

BIAN’s expectation is that a standard definition of business functions and service interactions that describe the general construct of any bank will be of significant benefit to the industry”.

Zafin agrees with BIAN’s standards.

Upon landing on the BIAN reference model page, the abundance of models can be overwhelming, but we utilized just the two models in red. Also the Service Landscape Matrix view, while daunting itself, is a handy tool to locate business functions and service domains with. Use Ctrl-f instead of the search bar on the top-right of the page.

Figure 1: BIAN Architecture Reference Model

If you browse from the Information Architecture Overview to the Agreement BOM Diagram, you’ll find the picture that has inspired Zafin Agreements the most.

Figure 2: BIAN Agreements BOM

In yellow are the primary Business Objects that make up Zafin’s business domain. The business objects in bright blue associate the primary objects. Ignoring the green sections for now, several important concepts stand out:

1. An Account is not directly related to a Party, Agreement links the two.
2. An Agreement associates a Product to a Party via Agreement Involvement.
3. An Arrangement lives only within the context of an Agreement.
4. Agreements can be linked via Agreement_Agreement Relationships.

These 4 concepts have been adopted as-is, in the Zafin Agreements design.

The green boxes depict a fifth important BIAN concept that we have embraced:

5. All BIAN Business Objects are of a Type.

BIAN uses Type Values (TVs) to classify instances of Business Objects with. We found this to be an elegant way to allow for bank-specific idiom, whilst retaining a strongly typed model.

The sixth adopted BIAN concept is the breakdown of business domains into service domains. We found the BIAN service domains to be too atomic to serve as the foundation for our software modules but:

6. All BIAN semantic APIs, for the service domains we have in scope, are easily recognizable, by any BIAN-aware bank.

The BIAN reference models are not without a few shortcomings. At times business concepts seem to be missed (i.e. product hierarchies). In other cases, Type Values are insufficient for the North American market, begging for more standardization by BIAN. This is why Zafin Agreements is still inspired by BIAN and not fully BIAN adept. Before we get into how the BIAN concepts have been applied, there is an important question to answer first; why adopt the BIAN standard?

Why adopt BIAN?

Where many banks are dissecting their monolithic estate to implement best-of-breed solutions to connect their digitally transformed channels with thin account management cores, these banks are increasingly adopting BIAN. Many of the larger North American banks have been BIAN members for years, no less then 22 new banks became a BIAN member last year. Banks believe BIAN to “enable more efficient and effective development and integration of software solutions for and between banks”. And rightfully so with Open Banking regulations on the rise and the integration of ISO, out of the box.

Why would you as a banking engineer want to adopt the BIAN models? How much time has been sunk into endless conversations with clients on element definitions or allowed enumerations? How much more efficient would it be to not impede your design work for a couple of sprints, with a statement like this?

“While we await requirements, refer to this API for semantic guidance. These are that Zafin has harvested for this service domain already, for you to amend or add to”. Less conversations needed on interface specifications between engineers, “lowers overall integration efforts significantly” resulting in faster time to market.

The adoption of your software is all about the quality of your APIs. The success of your software is determined by your ease of integration and the delivered business value it will add. If there is a common vocabulary for all things banking and everybody in the industry speaks it, why invent another?

The Open Banking (OB) APIs are here to stay and entering governments are likely to adopt standards of maturing government bodies. There is a “current need for more industry integration through the usage of open APIs”. BIAN has the best coverage across banking business domains, with the inclusion of ISO (and ACTUS recently) to become the Open Banking glossary.

As with any standard, its legitimacy comes with its degree of adoption. While standards like ISO and FPML remain relevant, IFX and IFW fade away. For BIAN to “support the adoption of more flexible business service sourcing models and enhance the evolution and adoption of third-party software”, adopting BIAN should become a self-fulfilling prophecy with both banks and banking software vendors, to converge to a concept-of-one.

What is Zafin Agreements?

With the WHAT and WHY of BIAN explained, we touch on the WHAT of Zafin Agreements before we delve into its design. This is because for Zafin to adopt BIAN Service Domains (SDs), and its semantic APIs, we need to understand the scope of the service domains that Zafin manages and Zafin interacts with.

Overlaying BIAN service domains on the context of a bank interacting with Zafin SaaS, we would depict a Context diagram like this:

Figure 3: Zafin Agreements System Context Diagram

To understand our current state in terms of BIAN service domains, the following table shows some of the SDs we support through our software solutions.

Table 1: Service Domains supported by Zafin Agreements

The table suggests that we have built duplicate features into Zafin Agreements, which is partly true, we will explain that in a bit.

Zafin Agreements Business Object Model

This is Zafin’s interpretation of the BIAN Agreements BOM. Our Minimum Viable Product (MVP) implements this Entity Relationship Diagram (ERD) to the letter, it became our service domain model of sorts as well. The diagram articulates well we think, Zafin’s conformance to the first four BIAN inspired concepts.

Figure 4: Zafin Agreements Business Object Model

Zafin Agreements APIs

To support concept 6 (our APIs are recognizable by BIAN-adept banks) we must first scope our BIAN Service Domains. The following BIAN SDs are in scope:

1. Sales Product
2. Customer Products and Services
3. Customer Product And Service Eligibility
4. Party Reference Data Directory
5. Product Directory

Because of the size of our team, we decided to merge domains 1, 2 & 3 into Sales Product Agreement (SPA). Both directories (PRDD & PD) are separate modules, loosely coupled to SPA. With scope in terms of BIAN semantic APIs now defined, let’s scope the endpoints within these APIs.

These are some of the endpoints we support in MVP1 of Zafin Agreements, they link to the BIAN semantic APIs on which they are based:

• POST /salesProductAgreement/v1/productAndServiceAgreement/evaluate
• PUT /relationshipManagement/v1/customerProductsAndServices/{PRDD_id}/request
• POST/partyReferenceDataDirectory/v1/{PRDD_id}/register
• POST/relationshipManagement/v1/customerProductAndServiceEligibility/{PRDD_id}/evaluate
• GET/productDirectory/v1/{PD_id}/salesAndMarketing/retrieve

In the BIAN Sales Product SD for example we found semantic inconsistencies between the SD control record and the Agreements BOM. In early stages of our MVP, while constantly adding elements and entities, we found the translation from BOM to API control records, to be too cumbersome and less automate-able. We decided to stick to our Agreements BOM also for API payloads.

So why did we duplicate features of the Product Directory SD and the Product and Service Eligibility SD, within the new Zafin Agreements software?

For the Product Eligibility SD, we needed service-orchestration capabilities to fetch existing agreements. Like so adding more business value to the existing eligibility checks as our current software cannot orchestrate APIs across other Zafin software assets. We therefore implemented a BIAN “Legacy Wrapper” pattern and we leverage Temporal for orchestration.

We also made a BIAN-based read copy from our existing Enterprise Product Catalog (EPC) and named it Zafin Product Directory. The existing EPC software has a DSL-driven development approach. This approach works very well for quickly delivering custom product catalogs to banks, but the generated DB schema and its generic event publications make it more challenging to build new software on top it.

The idea here is to create a one common Zafin Product Directory data model to serve as a schema foundation for new solutions and as a highly resilient high performing read cache. An example would be the Product Explorer, coming soon, that combines the bank product configurations with analytical (revenue) insights from Zafin Data Fabric.

Conclusion

We hope you found this article to be helpful. We are always learning, so if you have any suggestions or experiences adopting BIAN, please share them in the comments section. We love to hear and learn from others.

The next BIAN related article will be on our take to BIAN business scenarios and we’ll discuss to go less relational with our physical database and store most of the BOM in a JSONB to not have to change our schemas when a bank asks us to store more data points.

References

1. BIAN Organization Home (no date) BIAN. Available at: https://bian.org/ (Accessed: 01 May 2024).
2. The ISO 20022 repository (no date) ISO20022. Available at: https://www.iso20022.org/financial-repository (Accessed: 01 May 2024).
3. BIAN Architecture Overview Portal v.12.0 (no date) InSite. Available at: https://bian.org/servicelandscape-12-0-0/index.html (Accessed: 01 May 2024).
4. BIAN Service Landscape V12.0 matrix view (no date) InSite. Available at: https://bian.org/servicelandscape-12-0-0/views/view_51891.html (Accessed: 01 May 2024).
5. BIAN Agreement bom diagram (no date) InSite. Available at: https://bian.org/servicelandscape-11-0-0/views/view_52432.html (Accessed: 01 May 2024).
6. BIAN Business Object (no date) Insite. Available at: https://bian.org/servicelandscape-12-0-0/object_28.html?object=64173 (Accessed: 01 May 2024).
7. BIAN Business Domain (no date) Insite. Available at: https://bian.org/servicelandscape-11-0-0/object_10.html?object=65111 (Accessed: 01 May 2024).
8. BAIN Agreement (no date) Insite. Available at: https://bian.org/servicelandscape-12-0-0/object_26.html?object=36783 (Accessed: 01 May 2024).
9. BIAN Arrangement (no date) Insite. Available at: https://bian.org/servicelandscape-12-0-0/object_25.html?object=33524 (Accessed: 01 May 2024).
10. Canada, D. of F. (2023) Government of Canada — Final Report — Advisory Committee on Open Banking, Canada.ca. Available at: https://www.canada.ca/en/department-finance/programs/consultations/2021/final-report-advisory-committee-open-banking.html (Accessed: 01 May 2024).
11. BIAN Sales Product API Specification (no date) SwaggerHub. Available at: https://app.swaggerhub.com/apis/BIAN-3/SalesProduct/11.0.0 (Accessed: 01 May 2024).
12. Financial products markup language (no date) FpML. Available at: https://www.fpml.org/ (Accessed: 01 May 2024).
13. Implementing Bian Service domains using the IFX Business Message Specification (no date) BIAN. Available at: https://bian.org/deliverables/white-paper/implementing-bian-service-domains-using-the-ifx-business-message-specification/ (Accessed: 01 May 2024).
14. The Information Framework (IFW). Available at: https://public.dhe.ibm.com/software/data/mdm/pdf/IFW_Poster_2006.pdf (Accessed: 01 May 2024).
15. 4.3.1 Legacy Wrapping Approaches — Bian Semantic Api Practitioner guide V8.1. Available at: https://bian.org/wp-content/uploads/2020/10/BIAN-Semantic-API-Pactitioner-Guide-V8.1-FINAL.pdf (Accessed: 01 May 2024).
16. Temporal.io — Open source durable execution (no date) Open Source Durable Execution | Temporal Technologies. Available at: https://temporal.io/ (Accessed: 01 May 2024).
17. DSL Guide (no date) martinfowler.com. Available at: https://martinfowler.com/dsl.html (Accessed: 01 May 2024).
18. Zafin Studio: Your gateway to innovation in banking (2024) Zafin. Available at: https://zafin.com/studio/ (Accessed: 01 May 2024).
19. Zafin Data Fabric (2024) Zafin. Available at: https://zafin.com/zafin-data-fabric/ (Accessed: 01 May 2024).
20. Oyama, F. (2024) PostgreSQL and JSON — how to use JSON data in PostgreSQL, freeCodeCamp.org. Available at: https://www.freecodecamp.org/news/postgresql-and-json-use-json-data-in-postgresql/ (Accessed: 01 May 2024).