Eyal Sivan
Contributors: Ryan Waters, Eyal Sivan, Chris Wood
The following guide provides insight and direction to technology teams at banks, financial institutions and other financial data-holders in the US ecosystem who are preparing to comply with Section 1033, the open banking regulation recently passed by the US CFPB.
Section 1033 of the Dodd-Frank Wall Street Reform and Consumer Protection Act gives US consumers the right to access their own financial data, and to direct that data to third parties of their choosing, in a usable electronic format. For over a decade, the provision sat largely dormant: a grant of authority the CFPB had not yet turned into an enforceable rule. Banks and fintechs built data-sharing relationships anyway, through bilateral agreements and screen-scraping arrangements that varied wildly in security and reliability from one institution to the next.
That changed on 22 October 2024, when the CFPB finalised its Personal Financial Data Rights rule. The rule requires data providers (banks, credit unions and card issuers) to make specified categories of consumer financial data available through secure, standardised APIs, at the request of the consumer, to authorised third parties. It set out a phased compliance timeline based on institution size, described requirements for consumer consent and authentication, and pointed toward industry-developed technical standards rather than a CFPB-authored specification.
The goal remains, but the rule’s legal footing has changed. Within hours of finalisation, a group of banks and trade associations sued the CFPB, and the rule has spent most of the time since in litigation and, more recently, in the CFPB’s own hands for reconsideration. Currently, the rule is enjoined and not currently enforceable, while the Bureau works on a replacement or amended version.
This guide focuses on the technical foundations a bank or fintech needs regardless of how the legal process resolves: consensus API standards, trust frameworks for authenticating third parties, consent mechanics, consumer-facing UX, and secure data access. Those foundations were sound in January 2025 and remain sound today.
The CFPB finalised its Section 1033 Personal Financial Data Rights rule on 22 October 2024. That same day, Forcht Bank, N.A., the Kentucky Bankers Association and the Bank Policy Institute sued the Bureau in the US District Court for the Eastern District of Kentucky (case 5:24-cv-00304), arguing the rule exceeds the authority Congress gave the CFPB under Dodd-Frank Section 1033, unlawfully bans banks from charging fees for interface access, and fails to properly safeguard consumer data. The Financial Technology Association intervened in May 2025 to defend the rule.
The case then took an unusual turn. Under new leadership, the CFPB itself shifted position in May 2025 and signalled it wanted to reconsider its own rule. Litigation was stayed on 29 July 2025 while the Bureau began new rulemaking. Then, on 29 October 2025, Judge Danny C. Reeves issued a preliminary injunction barring the CFPB from enforcing the rule while that reconsideration is under way. The court found the bank plaintiffs were likely to succeed on their claims that the rule exceeds the CFPB’s statutory authority, is arbitrary and capricious, unlawfully bans fees, and sets compliance deadlines tied to standards that did not yet exist when the rule was written.
It is important to be precise about what that means. The rule is enjoined, not vacated. It is still on the books, but the CFPB currently cannot enforce it. Both the FTA and the CFPB have filed notices of appeal to the Sixth Circuit, but that appeal is itself stayed as of mid-2026 while the Bureau’s new rulemaking proceeds. No appellate ruling exists as of this update.
On the rulemaking side, the CFPB published an Advance Notice of Proposed Rulemaking, “Personal Financial Data Rights Reconsideration,” on 22 August 2025. The comment period closed on 21 October 2025 with nearly 14,000 comments filed. As of August 2026, a new proposed rule has reportedly been sent to the White House Office of Information and Regulatory Affairs for review, but nothing has been published in the Federal Register. Industry reporting suggests the CFPB may replace the outright fee ban with a model that permits fees above a free-access threshold. That’s worth tracking, but it isn’t confirmed, and we’ll update this guide once it is.
That leaves the original compliance timeline in limbo rather than cancelled:
| Tier | Institutions | Original compliance date |
| 1 | Depositories $250bn+ assets / non-depositories $10bn+ receipts | 1 April 2026 |
| 2 | Depositories $10bn to $250bn | 1 April 2027 |
| 3 | Depositories $3bn to $10bn | 1 April 2028 |
| 4 | Depositories $1.5bn to $3bn | 1 April 2029 |
| 5 | Depositories $850m to $1.5bn | 1 April 2030 |
These dates are still the plan, but they are not currently operative enforcement triggers given the injunction, and no replacement dates have been confirmed.
What hasn’t stopped moving is the market. Through 2025, JPMorgan Chase began charging data aggregators for API-based access to customer data that had previously been free. FDATA’s executive director, Steve Boms, called the fees “unlawful tolls,” while the Financial Technology Association and American Fintech Council raised separate objections of their own. By late 2025, JPMorgan had reportedly reached fee agreements with several aggregators, including Plaid, Yodlee, Morningstar and Akoya. Whatever happens to the federal rule, bilateral commercial data-sharing arrangements between banks and aggregators are being negotiated and priced right now.
The practical takeaway for a bank technology or compliance team: don’t wait for legal certainty before you build the standards-based plumbing. The rule’s fate may be uncertain, but the direction of travel, toward standardised, consent-based, API-first data sharing, is not.
The creation of open banking ecosystems is inextricably linked with the creation, description and implementation of standardised Application Programming Interfaces, or APIs for short. All current open banking standards, including the Financial Data Exchange (FDX) standard created by and for the US market, are based on APIs that communicate over HTTP using JSON to send and receive data. OpenAPI specifications provide the basis for creating API requests and responses within the ecosystem, ensuring the required data attributes are well understood by API providers and consumers. FDX and other global standards also adopt security standards such as the Financial Grade API profile (FAPI), an OpenID Connect (OIDC) profile specifically designed for financial services and open banking use cases.
Note that compliance with a given standard’s data framework is distinct from compliance with its security framework, and certification mechanisms often test these two separately. At the time of writing, the formal certification process for FDX has yet to be finalised and, as such, it is not yet clear whether participants will need to confirm only to the data framework or to the security framework as well. The Section 1033 ruling delegates this decision to the standards body, but does in fact recognize the distinction between a data model and a secure communication protocol in its definition of standard data format.
In the vast majority of regulated open finance markets, a participant must have an assigned role granted by the local competent authority for financial services, a role which can be programmatically verified via an ecosystem registry operated by that competent authority or their delegate. Such a certification and registration mechanism allows participants to automatically enter the ecosystem once they have been verified and concretely attested they can support open finance use cases, capabilities reflected in the respective security model. While Section 1033 recognises the value of such mechanisms, it will likely defer these to the standards-setting body. FDX has a rudimentary member registry today, but includes on its roadmap support a programmatic ecosystem registry.
The CFPB doesn’t dictate a single technical specification for these APIs. Instead, the rule relies on standards developed by CFPB-recognised industry standard-setting bodies. The Financial Data Exchange (FDX) was formally recognised by the CFPB as a standard-setting body on 8 to 9 January 2025, for an initial five-year term, with conditions barring “pay-to-play” arrangements that could let large members buy influence over the standard. As of August 2026, FDX remains the only CFPB-recognised standard-setting body.
FDX’s technical standard has kept moving even while the rule’s legal status hasn’t. FDX released API version 6.4 around 16 June 2025, which included two distinct, separately-named deliverables worth telling apart: a new CSDF Security Model and Profile, and a separate Consensus Standard Data Format (CSDF) v1, a data-formatting specification designed specifically to help data providers demonstrate indicia of compliance with the CFPB’s Personal Financial Data Rights (Section 1033) data-formatting requirements. The release also included an updated Consent API Behavioural Specification and revised UX guidance. FDX recently published 114 million active US and Canadian customer connections running on its standard, up from 94 million reported in September 2024: a sign that adoption has continued to grow through the litigation, not stalled because of it.
Agreement on the high-level technical model for communicating through APIs provides the means for establishing how Data Recipients and Data Providers can communicate securely, using a commonly agreed-upon trust framework. Third-party access has traditionally been enabled like any other API, namely through bi-lateral agreements between Data Recipients, Data Providers and any Data Aggregators. The benefit of a common trust framework is that bi-direction, proprietary trust mechanism can be largely replaced by a more scalable, consistent and secure alternative.
If the future model under Section 1033 is consistent with that in other markets, Data Recipients will likely obtain authorisation through a standards body recognised by the CFPB to support the enrolment and attestation of compliance for third party participants. The authorisation process is likely to involve the Data Recipient specifying their use case, the version of the technical standards they are using, as well as key contact details. The standards body may have a process for verifying the business identity alongside the specified contacts responsible for standards compliance at the organisation. As the CFPB has yet to specify which body provides this function, there may be a transitionary period whereby some form of bi-lateral agreements persist and Data Providers, as well as Data Aggregators, authorise third party Data Recipients themselves; however, this mechanism will evolve over time based on market and regulatory cooperation. Just as FDX is likely to be selected as a recognised standards setting body, they are equally likely to be responsible for establishing mechanisms for certification, registration and ongoing trust.
Once the Data Recipient has obtained authorisation from the body operating the recognised trust framework, they can begin the process of integrating directly with the Data Providers upon which their open banking use case will depend. This often begins with the Data Recipient registering with the Data Provider for API access.
Providing API access only to authorised third parties is critical to the functioning of an open banking ecosystem, and security frameworks like FAPI, FAPI 2 and OpenID Federation are designed to help this happen seamlessly. FDX and many other open finance standards support the OpenID Connect Dynamic Client Registration (DCR) profile to facilitate API-based onboarding of third party Data Recipients with Data Providers, without the need for any registration user interface. DCR allows the Data Recipient making an API request to specify the details of the API client they want to register via the Data Provider’s designated registration endpoint. The registered client details will include information like the name of the client product, description of the product, redirect URIs and logos.
This API registration process typically has multiple layers of security, including:
Data Recipients will first mutually authenticate with the Data Provider using certificates recognised within the shared API trust framework. This relies on Public Key Infrastructure (PKI), whereby the communication channel between the Data Recipient and the Data Provider is directly secured.
Once connectivity is established between the Data Provider and the Data Recipient, the Recipient must request an Access Token in order to register their client. The Data Provider will issue an Access Token which is strictly bound to the third party Client’s certificate, which the Data Recipient can then use to register a client with a Data Provider. The information registered can be verified by the Data Provider using the registry APIs provided by the trust framework, which will maintain the certification status of the Data Recipient. The organization details provided to the Data Provider by the Data Recipient would need to match the organization details held by the public registry at the standards setting body.
While Data Providers can grant ‘automatic’ approval to Data Recipients that meet all of the above criteria, there is also an option to create API Clients in a ‘pending’ status and have a separate manual, or ‘offline’ review process. Once registration is complete and the registered client is in an active authorisation status, the Data Recipient can invoke the Data Provider’s authorisation flow to facilitate access to customer data.
Although this is how many regions operate today, note that FDX have not yet been selected as a standards setting body by the CFPB, nor have they specified the exact technical mechanisms for providing this function programmatically. However, based on their roadmap and their ongoing analysis of other regions, it is fair to assume they are heading in the same direction as regards trust framework capabilities.
Until these automated mechanisms become available, registering for API access will continue to be a largely manual process based on bi-lateral agreements between Data Recipients and Data Providers, often facilitated by Data Aggregators acting as brokers. Nevertheless, preparation for more advanced mechanisms is highly recommended.
The FDX security standard implements the FAPI 1.0 Advanced Security Profile to provide secure API access for ecosystem participants.. FAPI is already used globally in open data specifications in markets such as the UK, Australia, the MENA region and South America. Any standards body endorsed by CFPB is therefore very likely to adopt the FAPI standards.
Note that at the time of this writing the adoption of FAPI is yet to be officially required by the CFPB or FDX, and there may be a transitionary period to enable the migration of existing security mechanisms towards FAPI 1.0 Advanced as defined in the FDX standard. To that end, there may be a period where adherence to the FDX data model is sufficient to achieve certification for the purpose of Section 1033 compliance, and that adherence to the FDX security communications protocol will not be initially required. The final Section 1033 ruling expands upon the definition of a ‘standardised format’ to include a secure communication protocol between Data Recipients and Data Providers, and the finalised FDX Certification process will likewise give further specificity on how both parties can achieve certification. Regardless of whether it is required for certification or not, the FDX security standard remains highly-recommended by the standards body itself, so the remainder of this section describes how exactly it operates.
The FAPI 1.0 Advanced Security Profile is a tailored OpenID Connect and OAuth 2.0 implementation suitable for financial services use cases. The Profile builds on the core goals of OpenID Connect (OIDC) to provide proof-of-authentication and authorisation by users so that data access is both secure and constrained to only the permitted data. Data security and control is paramount in open banking, as account-holding customers are trusting their data to third parties with whom they want to do business. A standard built around the exacting requirements of FAPI enables trust, and is therefore critical to the ultimate success of open finance ecosystems.
FAPI, like other OpenID Connect and OAuth implementations, mandates a specific flow that results in a Data Recipient being granted an Access Token to retrieve data from the Data Provider. In simple terms this flow implements the following three steps:
Pushed Authorisation Request (PAR) is an OAuth 2.0 profile and an optional element of FAPI 1.0 Advanced, already adopted by many global open finance frameworks such as the Australian Consumer Data Right (CDR) and the UAE Open Finance Framework (OFF). Although the Pushed Authorisation Request (PAR) standard is optional within the FAPI 1.0 Advanced profile, the FDX security standard declares it is mandatory. PAR Requests allow the Data Recipient to send the payload of the Authorisation request to the Data Provider’s PAR Endpoint before initiating the Data Recipient Authorisation process. The Redirect URI returned is then used in the subsequent call to the Data Provider’s Authorisation Endpoint. PAR provides heightened security for transmitting Authorisation request details as the payload is sent to a secure, backend URL, protecting sensitive information that would otherwise be sent in the browser.
Once the PAR Request is completed, the Data Recipient invokes an Authorisation Request to obtain an Access Token based on an Authorisation Code grant type. In the context of FDX, the key features of the requested authorisation are:
Successful Data Recipient Authorisation Requests will trigger redirection of the consumer (i.e. user) to the Data Provider’s Auth Service in order to perform End User Authentication and confirm Authorisation of the consent. End User Authorisation requests can only result in a successful initiation of the user interaction if the Client and the associated PAR Request URI can be validated, and if the redirection endpoint specified matches the details registered by the Data Recipient with the Data Provider. Successful completion of the user interaction will result in the Data Recipient receiving an Authorisation Code. At no point does the Data Recipient have access to the internal authentication / authorisation flow provided by the Data Provider to the user.
The final stage of the authorisation process involves a Data Recipient submitting a request to the Data Provider’s Token Endpoint, using the Authorisation Code in order to receive an Access Token and optional Refresh Token. The Access Token response received by the Data Provider will identify the scope of access granted by the Data Provider to the Data Recipient, and provide the Access Token lifetime in seconds. The Client can then use this Access Token in subsequent API calls to retrieve End User Data. This data is the actual covered data provided by the standardised API, such as account or transaction details.
Both the proposed Section 1033 ruling and the core principles of open banking necessitate the development of front-end interfaces able to support certain features. For Data Providers, this can be thought of in terms of two types of user – Data Recipients, meaning the third party participants using the consumers’ data to enable certain use cases; and End Users, meaning the consumers themselves, using the third party’s apps or tools.
When approving data sharing arrangements between Data Providers and Data Recipients, End Users should be able to perform several key functions in order to authorise access to their personal financial data:
In open banking standards, including FDX, these functions are often described in the User Experience Guidelines. The remainder of this section will address each in turn.
FAPI and other open banking API security standards do not typically define explicit technical requirements for authentication of the end user, relying on existing mechanisms implemented by the account-holding bank with high-level requirements like the use of multi-factor authentication (MFA). However, consumer authentication is a formal requirement of the Section 1033 ruling and is an implied necessity under the OAuth 2.0 authorisation framework. In order to achieve both a consistent user experience and a high level of security, Data Providers are likely to provide the same authentication process and login credentials used for general access to online or mobile banking when authenticating users. This will normally also mean that MFA is implemented, as it is often part of online banking already, with biometrics used as a strong indicator of customer identity. MFA takes place during Authorisation Code flow, when the End User is redirected to the Data Providers Authorisation Server to authenticate and authorise access.
Confirmation of consent is not a formal requirement of Section 1033. However, Data Providers are encouraged to confirm with the End User the following information regarding a consent:
From a user experience perspective, the Data Provider needs a mechanism to retrieve a list of the user’s accounts and the scope of access requested by the Data Recipient, which the Data Provider will present to the user in their digital channels. In the FDX standard, the scope of data to be shared is uniquely identified by the PAR Request URI provided by the Data Provider to the Data Recipient. The Data Recipient uses the PAR Request URI as an argument during Authorisation Code flow, which enables the Data Provider to verify the consent. Presenting the consent to the consumer to confirm within the digital channel ensures the consumer has a final opportunity to review the details associated with the consent before they authorise data access and are redirected back to the Data Recipient. As above, the consent should include details on the identity of the Data Recipient, the specific accounts being covered, and the respective data being shared.
Another common user experience (UX) function within open banking is the ability to manage authorised consents often referred to as a ‘consent dashboard’. Section 1033 encourages Data Providers to provide consent management capabilities, including a consent dashboard, provided that this does not in any way discourage the user from maintaining authorised access to data and utilising Data Recipient services. Section 1033 also references ‘adherence to industry standards’ in respect to consent dashboards as a way to provide evidence that consent revocation mechanisms provided do not present a hindrance to Data Recipients
FDX provides detailed UX guidance giving a general overview of how Data Providers (and Data Recipients) should present consent-related information to users in their digital channels, which includes consent dashboard functionality. FDX also provides guidance on permissions language linking specific OAuth 2.0 authorisation scopes to more user-friendly descriptions of what these data scopes mean to the end user.
Under the FDX UX guidelines, which match industry conventions, a consent dashboard should able to provide the following core capabilities:
The consent details presented to the user should at a minimum specify information such as the Data Recipient details, the accounts authorized for data sharing, the scopes of data being shared and the sharing duration. Other capabilities like bulk consent management are capabilities that can enhance the customer experience, and Data Providers may consider adding them in order to improve usability.
Data Providers are obliged under Section 1033 to provide developer documentation. This documentation acts as a specialized channel for providing developers at a Data Recipient with all the information they require to integrate with a Data Provider’s APIs.
A Data Provider’s developer portal should meet several requirements, including but not necessarily limited to the following:
Many FI’s already provide non-regulated third party integration capabilities. The accepted industry principles and capabilities of good developer documentation are applicable here, namely well described APIs, helpful developer tools, detailed documentation, and any other means to provide a good-quality developer experience (DX).
Once consent has been established and the third party Data Recipient has a valid Access Token, access to Section 1033 covered data is secured by a variety of common API and network security mechanisms including:
MTLS provides transport layer security, implemented using certificates trusted by both the Data Recipient and Data Provider. This will provide a secure communication channel, in a similar way to other FAPI endpoints, and even in instances where FAPI is not being used.
Once a valid connection is established, a Data Recipient will rely on an Access Token with the corresponding authorisation scopes in order to access a Data Provider’s resource endpoints. Access tokens can be generated only via the OAuth 2.0 consent authorisation flow, and the Data Provider will be able to verify the authorisation scopes through introspection against the stored consents for the registered user, using the Access token to correlate the corresponding Consent ID.
All requests for data access will additionally be secured using digital signatures. Participants can implement payload signing, based on the provisions of the standards, using agreed upon signing keys shared for verification using mechanisms such as JSON Web Key Sets (JWKS).
Additional measures that can be implemented include masking of sensitive data. Sensitive data typically includes Personally Identifiable Information (PII), such as bank account or credit card numbers. PII can be provided in masked or tokenised format, to ensure that it is not unnecessarily shared by the Data Provider to the Data Recipient. Masking or tokenisation is implemented where there is not a genuine use case for sharing the sensitive data, therefore adhering to the principle of data minimisation.
The Section 1033 ruling enshrines regulated access for Data Recipients to certain categories of consumer data, as defined by the CFPB. The high-level categories described by the CFPB can be qualified into one of the following;
Data Providers must make covered data available in a standardised format, which should either be based on a widely accepted standard for data sharing, or a designated industry standard from a designated standard setting body, such as FDX.
The remainder of this section goes through each of these three data categories in turn, describing the API operations which need to be supported as per the FDX API specification. Note that the operations described below are not exhaustive of what is covered by FDX, but rather indicative of what a data request via FDX would look like.
Assuming a Data Recipient can be identified by the Data Provider, and has the consumer’s explicit consent, they are able to access the consumer’s data using an Access Token. FDX provides a Customer API, allowing Data Recipients to obtain either granular or high-level information on the customers associated with a consumer financial account;
These endpoints return standardised response schemas containing personal data attributes such as Name, Address, Date Of Birth, Government IDs and Contact Details. This allows Data Recipients and Data Access Platforms (also known as Data Aggregators) to facilitate various forms of Identity Verification use cases whereby many Data Providers implement the same, standardised high-quality data outputs via open banking APIs.
Probably the most critical component of data access for authorised Data Recipients is the ability to retrieve consumer account data from the Data Provider, such as detailed information on the balances and transactions from the payment accounts owned by the user. This is facilitated within the FDX standards by APIs such as:
Many open banking use cases rely on the ability for Data Recipients to get an aggregated view of the consumer’s financial life using information from one or more Data Providers for a single consumer. Use cases include verifying affordability in the context of lending, or providing automated financial management tools and tailored financial advice.
FDX provides detailed API response schemas linked to the specific type of consumer financial account – for example, Deposit, Line of Credit, Investment and Business Accounts.
As regards Payments data, Section 1033 requires that all the information ‘necessary to complete a payment’ be made available; however, a payment initiation API similar to that in other regions is not in scope. For its part, the FDX specification does include some limited Payments capabilities, but these are not likely to be required for certification.
Covered data under the Section 1033 ruling extends to details on the product information associated with the account type, such as reward programs, terms and conditions, fees and overdraft arrangements.
When this information is coupled with the consumer’s account data, this facilitates further potential use cases for Data Recipients and Data Access Platforms, such as product marketplaces and account switching services.
Note that, as of this writing, the FDX specification includes fields for Annual Percentage Rate (APR) and Annual Percentage Yield (APY) as part of the Accounts API, but does not include an API specification for generalised product information or terms and conditions. However, these may be added in the future based on member demands.
The honest operational answer for a bank technology or compliance team in August 2026 is that the compliance clock has stopped, but the engineering work hasn’t gotten any smaller. A few things are worth planning around:
Treat the current legal pause as a delay, not a cancellation. The CFPB has committed to a replacement or amended rule, an ANPR has already drawn nearly 14,000 comments, and a draft is reportedly sitting with the White House for review. When a new rule lands, the institutions that had already started building standards-based APIs will have a real head start over those that stood down entirely.
The timeline above through to 1 April 2030 is still the codified text, but they’re not currently enforceable, and no replacement dates have been confirmed. Rather than picking a new date out of the air, we’d suggest using the original tiers as a rough sequencing guide for internal planning, while staying ready to move if a new rule sets different dates.
The litigation’s core objection was the outright ban on interface-access fees. Reporting suggests the CFPB’s replacement rule may allow fees above a free-access threshold rather than banning them outright. If that holds, it changes the commercial calculus for data providers: access fees stop being purely a compliance cost centre and start being a genuine monetisation lever, which is exactly the kind of API economics Ozone API’s platform is built to support.
There is no comprehensive CFPB rule or guidance that allocates liability between data providers, aggregators and third parties when data access goes wrong. Today, that’s handled through private, bilateral contracts, and it was one of the most contested points in the 2025 rulemaking comments. Institutions building third-party access programmes now should assume they’ll need contractual liability terms with each counterparty, regardless of what the eventual rule says.
JPMorgan Chase’s move to charge aggregators for API access through 2025, and the fee agreements it subsequently reached with Plaid, Yodlee, Morningstar and Akoya, shows that large data providers are already renegotiating commercial terms for data sharing on a bilateral basis. Whatever the CFPB ultimately requires, standardised, monetisable data access is becoming normal market practice ahead of any mandate.
This is the practical conclusion we’d draw: FDX, FAPI-aligned security and consent-driven consumer experience aren’t going away, whatever the Sixth Circuit or a new CFPB rule ultimately decides, because they’re the same standards underpinning open banking and open finance regimes outside the US too. Infrastructure built to those standards holds its value across outcomes. Infrastructure built to hit one specific version of one rule’s specific deadline is a much riskier bet right now.
Ozone API provides a turnkey open finance platform which supports all the open banking standards and regulatory frameworks in the world. We already support the core standards underpinning open banking in the US, including the FDX data specifications, as well as the latest version of FAPI 1.0 Advanced and other security standards included in the FDX security specification. Open banking / finance standards will continue to evolve in the US far beyond the initial CFPB Section 1033 ruling and the current version of FDX, so working with a partner who understands how to build, maintain, and leverage open finance standards for commercial benefit is critical .
The infrastructure you build with us today is a foundation for compliance whenever it lands, and for the commercial APIs and embedded finance products you can build on top of it.
Get in touch with our team to talk through what a standards-based Section 1033 strategy looks like for your institution.
Open banking revenue models are the commercial frameworks banks use to generate income from their open banking infrastructure, beyond the regulated minimum of free API access for licensed third parties. Regulation sets the foundation. What a bank builds above that base, and how it prices it, is what determines whether open banking becomes a cost...
Phoebe Singer
Los bancos argentinos llevaban tiempo esperando saber qué les exigiría concretamente el esquema de Finanzas Abiertas (Open Finance). Esa espera concluyó con la emisión del Decreto 353/2025 en mayo de 2025. En la práctica, este decreto ubica a la Argentina en la misma senda regulatoria que los regímenes de Open Banking a nivel internacional. Aunque...
Fabio Caldeira
The Next Phase of KSA Open Banking Under the leadership of the Saudi Central Bank (SAMA), the Kingdom of Saudi Arabia continues to advance its Open Banking Framework as a core component of Vision 2030’s digital transformation agenda. Following the rollout of Account Information Services (AIS), the market is entering its next critical evolution: Payment...
