Data Modeling

1. Introduction

Banking, for most of its history, has been a fairly closed affair — a customer's transaction history, balances, and account details lived inside a single institution's walls, accessible mainly to that institution and, grudgingly, to the customer themselves. That arrangement is now being pulled apart, gradually and not always comfortably, by a combination of regulation and technology that goes under the banner of “open banking.” At its core, open banking is a fairly simple idea: banking data can be shared, with the customer's consent, between two or more independent parties through Application Programming Interfaces, opening the door to services that no single bank could easily build alone (Arner et al., 2021).

APIs themselves are, of course, nothing new — the concept traces back to the mainframe era, and one of the earliest enthusiastic adopters was, somewhat unexpectedly, the investment management industry, which used early API-like connections to pull third-party quotes and fund performance data onto a desktop program (Lundqvist, 2018; Paliwal, 2021). What changed things was the rise of the consumer internet in the early 2000s: eBay's decision to open parts of its platform to approved partners, and Salesforce's release of an API as part of its broader cloud strategy, are often cited as turning points, and by the following decade Facebook and Google Maps had shown just how far an ecosystem could be extended by simply inviting outside developers in. Banking, it seems fair to say, arrived at this realization somewhat later than other industries — API-based account access existed in the United States and Canada for some years already (Badour & Presta, 2018; Zachariadis, 2020; Diro 2022; ), largely in the form of personal finance software and bill-display integrations, but a comprehensive, regulation-backed model did not really take shape until Europe moved to require it.

That regulatory push came in the form of the Second Payment Services Directive, or PSD2, adopted in October 2015 as an extension of the original 2007 directive and intended, broadly, to make cross-border payments both easier and more secure while requiring banks to open customer data to authorized third parties (Coste & Miclea, 2019; Gauci, 2019; McKinsey & Company, 2018;). Before this shift, the only way most third-party applications could reach a customer's bank account was through screen scraping — a practice in which the customer hands over their actual login credentials to a third party, which thrinien logs in on their behalf and, in effect, copies the account data it needs (Badour & Presta, 2018; Muqorobin et al. 2021; Pandy 2020). It worked, more or less, but it required customers to give up their credentials entirely, and it left banks with little visibility into who was accessing their systems or why. Open banking APIs were meant to replace that arrangement with something narrower and more auditable: instead of credential sharing, the customer authorizes a specific, revocable scope of access, and the third party never sees the underlying password at all.

Whether this shift is, in practice, unambiguously positive is less settled than the regulatory literature sometimes implies. It is one thing to build a more secure technical channel; it is another to persuade a customer, who has spent a lifetime treating bank credentials as something never to be shared, that handing data access to a fintech app is safe. This tension — between what the technology and regulation now permit and what customers, and frankly banks themselves, are willing to embrace — runs through much of what follows.

2. Methodology

This paper is constructed as a review rather than a primary empirical study, and it is worth being explicit about that distinction up front, since the original framing of this work referenced field interviews conducted between July 2016 and February 2017 without documenting a protocol, sample, or analysis procedure sufficient to reconstruct or verify that primary research. In the interest of transparency and reproducibility — and in keeping with the expectation that a methods section should allow another researcher to retrace the same steps — this revision instead describes, in full, the literature-synthesis approach actually used to compile the present review, and flags where the underlying source material referenced empirical claims that could not be independently traced to a documented methodology.

2.1 Search strategy and sources

Sources were drawn from a combination of peer-reviewed journal articles, regulatory and central-bank publications, working papers, and, where relevant to describing current industry practice, publicly available reports from financial-technology providers. Search terms centered on combinations of “open banking,” “open API,” “PSD2,” “screen scraping,” “account aggregation,” and “fintech regulation,” applied across general academic search and publisher repositories, supplemented by targeted searches of central-bank and regulatory-body publication archives (e.g., Bank Negara Malaysia, the Federal Reserve Bank of Boston) given their direct relevance to API-based banking policy.

2.2 Inclusion and exclusion criteria

Sources were included if they addressed open banking, API-based financial data sharing, or PSD2 directly, and were published between approximately 2012 and 2022 — a window chosen to capture both the pre-PSD2 landscape and the several years of implementation experience that followed the directive's 2015 adoption. Purely promotional vendor material was excluded from the evidentiary base wherever it made unverifiable quantitative claims; where such material is referenced below (for instance, in describing how a specific commercial API functions), it is identified explicitly as a description of current industry practice rather than as independent empirical evidence.

2.3 Synthesis approach

Because the included sources span regulatory analysis, adoption-focused survey research (e.g., studies of mobile-banking adoption behavior), and descriptive industry reporting, a narrative rather than statistical synthesis was used: sources were grouped thematically — regulatory context, stakeholder perspectives (banks, customers, fintechs), and applied use cases — and compared for points of agreement and tension. Where a quantitative claim appears in the discussion below (for example, reported figures on customer willingness to adopt API banking, or fintech investment trends) but could not be traced to a specific, citable primary dataset within the available source material, this is stated explicitly alongside the figure so that readers can weigh it accordingly rather than treat it as independently verified.

2.4 Limitations of this approach

A narrative review of this kind cannot substitute for a systematic review with pre-registered search protocols and dual-reviewer screening, nor can it substitute for the primary interview-based research the original work gestured toward but did not document. Readers seeking a fully reproducible, quantitatively grounded account of customer adoption rates or fintech investment trends should treat the figures discussed in Section 3 as indicative of the broader literature's tone rather than as precise, independently audited statistics.

3. Results and Discussion

3.1 How open banking APIs work

Mechanically, the relationship between a bank and a third-party provider (TPP) under an open banking model is fairly straightforward, even if the surrounding governance is not. A bank opens defined, secured endpoints into its core banking system; a third-party platform integrates with those endpoints and requests specific data or functions — an account balance, a transaction history, a payment initiation — through what is generally called an API call; and the third-party application then exposes that data to the end user through its own interface (Ann & Iqbal, 2017) (Figure 1). This is, notably, a narrower channel than screen scraping ever was: rather than handing over a password and letting a third party log in as the customer, the customer grants a scoped, revocable authorization, and the bank retains visibility into exactly which parties are calling its APIs and for what purpose.

From the customer's side, the experience is meant to feel almost incidental — a redirect to the bank's own login page, a credential entry, and a confirmation screen, after which the third-party app simply has the access it needs (Sullivan, 2022) (Figure 2). Providers such as Plaid, Yodlee, Apigee, and Xignite have positioned themselves as the connective tissue in this ecosystem, offering pre-built integrations across thousands of institutions so that an individual fintech company does not have to negotiate a bespoke technical relationship with every bank it wants to support (Cope et al., 2018). It is worth noting, too, that this intermediary layer is not merely a convenience; for smaller fintech firms lacking the negotiating leverage of an Apple or a Google, standardized open banking APIs are arguably what makes broad bank connectivity commercially feasible at all.

3.2 The PSD2 regulatory scaffold

None of this would have unfolded quite the way it has without PSD2. Adopted in October 2015 as a successor to the original 2007 directive, PSD2 requires banks operating in the EU and EEA to provide regulated third parties with access to customer account data, provided the customer consents (Gorzala, 2020; Zachariadis, 2020). Among its more consequential provisions is Strong Customer Authentication (SCA), intended to curb online payment fraud — though its rollout was, by most accounts, bumpier than regulators initially hoped, with low consumer awareness and retailer readiness prompting a deferral of full enforcement into 2020 amid concern over lost transactions and cart abandonment (Zachariadis, 2020). Reading across the regulatory commentary, PSD2 comes across less as a single decisive event and more as an ongoing negotiation between the goal of an open, standardized market and the practical difficulty of getting an entire continent's banks, merchants, and customers to move in step (Pike, 2018).

3.3 Stakeholder perspectives: customers, banks, and the anxiety of sharing

The literature on stakeholder response to open banking is, frankly, more cautionary than the technology narrative alone would suggest. On the customer side, adoption-behavior research — much of it conducted in the context of mobile banking rather than open banking specifically, but instructive nonetheless — has found that gender, education, and income shape willingness to adopt digital

Table 1: Reported Indicators of Open Banking Adoption and Investment (as Cited in the Secondary Literature). Note. These figures are reported as they appear in the secondary/industry literature synthesized for this review. No independently auditable primary dataset could be traced for these specific values; they are presented as indicative of the literature's general tone rather than as verified statistics.

Figure 1. The Open API Authorization and Data-Request Flow Between Developers, Customers, and Third Parties. This figure illustrates how a developer connects to a third party's open API, which any developer can access because the API is open by design. It then shows a customer initiating a request (e.g., to view an account balance) from within the developer's app, with the request transmitted via the API. Finally, it depicts the third party receiving the request and its systems automatically returning the requested data through the same API channel. Together, the panels trace the full round-trip of an open banking API transaction from initial connection to data delivery.

Figure 2. The Open Banking API Process From the Customer's Perspective, Connecting a Banking App to Multiple Banks. This figure shows a customer-facing banking app displaying account balances (a current account, a second current account, and a credit card) alongside a central user icon representing the customer. Arrows illustrate data flowing bidirectionally between the customer and an API hub, which in turn connects to three separate bank institutions on the right. The diagram demonstrates how a single app can aggregate and display financial data pulled from multiple banks simultaneously through standardized API connections. It visually reinforces the account-aggregation use case that is central to open banking's customer value proposition.

Figure 3. The Functional Domains of Open Banking Within the Fintech Ecosystem (Adapted from FSBT.TECH, "Open API Platform," 2019). This figure presents a wheel diagram with "Open Banking" at its center, surrounded by ten interconnected functional domains: strategy and business model, customer centricity, deals and structure, data management and analytics, technology, tax, cybersecurity, fraud, risk, and regulation. Each segment represents a distinct organizational or operational area that banks and fintechs must address when implementing open banking. The circular, unified layout emphasizes that these domains are interdependent facets of a single ecosystem rather than isolated concerns. The figure is adapted from an industry source (FSBT.TECH, 2019) and is used here to frame the multidimensional scope of open banking adoption discussed in the review.

financial tools, and that trust and security concerns, more than price or convenience, tend to dominate customer hesitation (Palani & Yasodha, 2012; Thakur & Srivastava, 2013). Reported industry figures, cited here with the caveat that a traceable primary dataset could not be located in the available source material, put customer support for API-based banking at a relatively modest level — on the order of roughly a quarter of customers surveyed globally — with the shortfall attributed less to outright opposition than to a lack of visible, tangible value customers can point to in exchange for handing over access to their data (Table 1).

Banks, for their part, do not appear to be uniformly enthusiastic either. The same body of literature that celebrates open banking's innovation potential also documents a real institutional anxiety: banks risk losing some control over the customer relationship and, in the more pessimistic readings, risk a degree of product cannibalization as third parties intermediate services banks once delivered directly (Gorzala, 2020). At the same time, non-bank competitors — pure-digital entrants, large technology firms, and a fast-growing fintech sector — have not been shy about entering the space; industry commentary describes fintech investment climbing from a comparatively modest base around 2010 to figures reported in the tens of billions of dollars by the end of the following decade, though again, as with the customer-adoption figure above, this specific investment trajectory is reported here as it appears in the secondary literature rather than as an independently verified dataset (Omarini, 2018; Zachariadis & Ozcan, 2017).

3.4 Applied use cases across the fintech ecosystem

Despite institutional ambivalence, the range of applications built on open banking APIs has, in practice, grown fairly quickly (Figure 3). Payment processors such as Adyen use open banking APIs for account verification and payment processing, while consumer-facing apps like Tikkie in the Netherlands allow peer-to-peer payments initiated through messaging platforms. Account-aggregation services — Plaid, which by some accounts connects to more than 11,000 financial institutions across the US, UK, Canada, and Australia, and Yodlee, which offers similar aggregation for developers — give customers a single consolidated view of accounts that might otherwise be scattered across several institutions (Cope et al., 2018). Personal finance management tools such as Mint and PocketGuard build on that same aggregated data to help users track spending and set savings goals, and small-business accounting platforms such as Xero and Wave use the same underlying connectivity to reduce the manual data entry that has traditionally burdened bookkeeping. Taken together, these examples suggest that wherever a service depends on knowing, reliably and in near-real time, what is actually happening in a customer's account, open banking APIs have found a foothold.

3.5 Security architecture and the trust problem

It would be a mistake, though, to treat the trust problem as merely a matter of customer perception rather than genuine technical stakes. Providers in this space generally layer several protections — standard encryption, Transport Layer Security, multi-factor authentication, continuous security monitoring, and third-party code review — around the authorization flow, and require credentialing before a financial institution's endpoints can be called at all (Sullivan, 2022). Whether that architecture is sufficient to earn the level of trust screen scraping never quite achieved is, in some sense, an empirical question the industry is still answering in real time; the technical case for open banking's superiority over credential sharing is fairly strong, but technical superiority and perceived trustworthiness do not always move in lockstep, and the modest customer-adoption figures discussed above (Section 3.3) suggest that gap has not yet closed.

4. Conclusion

Open banking, propelled in large part by PSD2 and comparable regulatory efforts elsewhere, has genuinely shifted what is technically and legally possible in financial data sharing, replacing a fragile credential-sharing model with a more auditable, consent-based one. Yet this review suggests the shift remains incomplete: fintech applications built on open banking APIs — account aggregators, payment processors, personal finance tools — have multiplied, but customer enthusiasm has lagged behind the technology's capability, and banks themselves remain visibly ambivalent about a model that asks them to share what has long been proprietary. The institutions that treat this moment as a strategic opportunity rather than a compliance burden, and that can demonstrate clear, tangible value to a still-hesitant customer base, seem best positioned to benefit as the ecosystem matures. Whether that maturation happens quickly or slowly will likely depend less on further regulation than on whether trust, gradually, catches up with what the technology already allows.

References