Russia Pushes Corporate Multibanking Forward with Updated Open API Standards
Russia is moving toward standardized Open Banking APIs that could let companies manage accounts held at several banks from one interface. The approach aims to solve a common pain point: a financial director who must decide which invoices to pay today while accounting for upcoming payroll, expected receipts, and already-sent payments.
The Bank of Russia reported in December 2025 that 19 organizations had tested the emerging standards during 2024 and 2025, producing working services for real clients. AFT published ten approved standards covering glossary, security profiles, consent flows, and account-data exchange for both individuals and legal entities. Updated versions of these specifications become mandatory from 1 October 2026.
The security layer relies on STO BR FAPI profiles built on OpenID Connect together with Russian cryptographic algorithms. Consent standards describe how a company grants, retrieves, and revokes access to its account information. Account-data standards define the actual REST methods for balances and statements.
However, the 2025 specification set does not yet include payment initiation. Teams must therefore continue to integrate with each bank’s existing payment API while using the new Open API layer only for read operations. This split creates extra work for reconciliation and error handling.
The article outlines a staged product roadmap. A first version can display balances and recent transactions with timestamps. Subsequent releases add obligation data from the accounting system, calculate truly available funds, prepare payment orders, and track execution statuses. Each step requires clear assumptions so that a finance director understands why certain amounts are shown as spendable.
Idempotency keys and detailed status values become critical when a network failure occurs after a payment request is sent. The service must distinguish between “accepted for processing,” “settled,” and “result unknown” to avoid duplicate payments across banks. The UK experience with sweeping VRP (Variable Recurring Payments) shows how pre-authorized transfers between a client’s own accounts can run without repeated confirmation, yet corporate supplier payments demand additional policy and legal work.
Cost and liability questions remain open. A company may pay for time saved by accountants, while an accounting platform or a bank itself may become the actual buyer. Hidden revenue-sharing arrangements between the service and banks must be disclosed to avoid conflicts of interest.
Finally, the text stresses that standardization saves effort only when the same code, error semantics, and status meanings can be reused across banks. NEOMSA APIM is cited as an example of an API gateway that can enforce per-application keys, rate limits, and audit logs while leaving signing rights with the bank and the accounting system.
Related articles
Russian CA TCI Integrates ACME Protocol to Automate TLS Certificate Issuance
The Technical Center Internet (TCI), part of RTK-COD, has deployed a production ACME server compatible with standard clients such as acme.sh, Certbot and lego. The implementation aligns the ACME state machine with the existing isolated signing infrastructure, Domain Control Validation mechanisms and mandatory Certificate Transparency logging to Yandex and VK CT logs. Certificate lifetimes are shortening industry-wide, with Web PKI limits dropping to 47 days by 2029, making manual issuance unsustainable. The service supports HTTP-01 and DNS-01 challenges, ECDSA P-256 keys and certificate revocation, while preserving the requirement for Subject/CN in CSRs and mandatory revocation reasons. A separate staging environment uses an internal CT log simulator for safe testing. Future plans include full multi-SAN support, ARI (RFC 9773) and removal of the Subject/CN restriction.
Hacker Attacks as Force Majeure: Russian and International Courts Diverge on Liability for Cyber Incidents
In November 2026, Russian hosting provider Beget suffered a major cyber attack that disrupted websites, virtual servers, email, DNS, and control panels for thousands of clients. Beget notified customers of circumstances resembling force majeure under Article 401 of the Russian Civil Code but stopped short of claiming automatic court recognition. Russian courts have reached inconsistent rulings on whether DDoS attacks and ransomware qualify as extraordinary and unavoidable events, examining factors such as attack scale, provider preparedness, and contractual obligations. International cases from France, Norway, the United States, and the Netherlands further illustrate that outcomes depend on evidence of prior security measures, backup integrity, and specific contractual language rather than the mere occurrence of an attack. Key precedents include disputes involving Timeweb, Expeditors, and Nordlo Haugesund where liability was limited or denied despite confirmed incidents. The analysis shows that even when force majeure is rejected, clients often struggle to recover full losses due to liability caps and proof requirements. Businesses are advised to maintain independent backups, review service agreements, and document incidents thoroughly to protect against financial exposure.
US Mandates Removal of Acronis from Federal Systems by January 2027 Over Russian Ties
US federal civilian agencies have been ordered to remove all Acronis products from their information systems by January 27, 2027, with new purchases also prohibited. The directive from the Department of Homeland Security, signed on July 31 and published in the Federal Register on October 30, covers Acronis AG along with Acronis Inc. and Acronis SCS. A nearly decade-long review examined whether Russian developers still access the code and whether supply chain risks have been sufficiently reduced, though no specific evidence of backdoors was reported by sources. After 2022, Acronis suspended operations in Russia and relocated specialists, while in 2025 Swedish firm EQT acquired a controlling stake with approval from the US CFIUS committee. Despite over 75 percent of shares now held by Western investors, these measures proved insufficient for continued access to federal systems. The ban does not extend to the private US market.
Google to Back Unified robots.txt Standard for Blocking AI Training Data Use
Google has announced plans to support a common mechanism in robots.txt that allows website owners to opt out of having their content used for training generative AI models. The feature will be based on work by the AIPREF working group at IETF and is scheduled for rollout in 2027. Instead of issuing separate instructions to each AI provider, publishers will be able to set a single policy marker that participating companies are expected to respect. Google intends to treat an unspecified general marker the same way it currently handles its own Google-Extended directive. Existing per-company rules will continue to function, letting site owners combine a broad default with specific exceptions. The approach simplifies management as the number of AI crawlers grows, though compliance will remain voluntary and dependent on which organizations adopt the standard.