# Formance — full content > Open, programmable financial infrastructure. Programmable ledger, payment flows, connectivity, and reconciliation. Generated from https://www.formance.com. Index: /llms.txt. Any page URL also serves Markdown with `Accept: text/markdown`. --- # Product pages --- title: "Money Movement Flows & Orchestration | Formance Platform" description: "Compose multi-step money movement—splits, fees, holds, payouts—as durable, event-driven programs that run reliably across providers with full auditability." canonical: "https://www.formance.com/platform/flows" slug: platform-flows type: page-lite updated: "2026-07-22T11:08:17.470Z" --- *_FLOWS/* # Money movement, orchestrated Compose multi-step payment workflows as durable, event-driven programs — reliable across every provider. Compose multi-step money movement—splits, fees, holds, payouts—as durable, event-driven programs that run reliably across providers with full auditability. ## Page sections ## Section 2: flowWorkflows *_WORKFLOWS/* ### Workflows as code #### Declare the whole journey, end to end. Describe splits, fees, holds and payouts as a single declarative program. Version it, review it, and ship money movement like any other code. --- ## Section 3: flowSend *_SEND/* ### One send, any rail #### Move value between ledgers, wallets and payments. A single send stage moves value between internal ledgers, wallets and external payments. Source and destination interchange freely — the engine resolves the route, including provider-specific paths like Stripe. --- ## Section 4: flowDurability *_DURABILITY/* ### Durable by default #### Every run survives time and failure. A workflow instance is a durable program: each stage is tracked with its status and timing, and long waits or delays hold their place for days without losing state. The run resumes exactly where it left off. --- ## Section 5: flowOrchestration *_ORCHESTRATION/* ### Durable orchestration #### Long-running flows that never lose state. Each stage runs as a durable step. Flows can wait for external events for minutes or months, then resume exactly where they left off — no lost work. --- ## Section 6: flowReliability *_RELIABILITY/* ### Retries & idempotency #### Exactly-once, even when rails fail. Transient failures are retried automatically with idempotency keys, so a flaky provider never double-charges or double-pays. Every attempt is recorded. --- ## Section 7: flowEvents *_EVENTS/* ### Event-driven by design #### Observe every step in real time. Flows emit a typed event stream you can subscribe to — drive notifications, analytics, and downstream systems from a single source of truth. --- ## Section 8: flowInstances *_INSTANCES/* ### Every run, inspectable #### Follow a workflow instance, stage by stage. Each run is a live instance you can inspect end to end — what has executed, what is waiting and why. Durable stages hold their place until the event arrives, so nothing is lost between steps. --- ## Section 9: flowTriggers *_TRIGGERS/* ### Triggered by events #### Start a workflow the moment it matters. Bind a flow to any platform event and filter it with expr-lang. When an incoming payment matches, its data is forwarded straight into the run as typed variables — no glue code, no polling. --- ## Section 10: flowFaq *FAQ* ### Questions, answered **DURABILITY** Each stage runs as a durable step. A flow can wait for an external event for minutes or months, then resume exactly where it left off. **IDEMPOTENCY** Retries use idempotency keys, so a flaky provider never double-charges or double-pays. Every attempt is recorded. **EVENT-DRIVEN** Flows wait on typed events and emit their own, so notifications, analytics and downstream systems run off one source of truth. **AUTHORING** Workflows are declared as code — versioned, reviewed and shipped like any other program, not built in an opaque visual editor. **OBSERVABILITY** Every stage transition is logged with its inputs and outputs, so a stuck or retrying flow stays inspectable in real time. --- ## Section 11: flowCta *_GET STARTED/* ### Orchestrate money movement that survives failure Durable, idempotent, event-driven workflows — reliable across every provider. --- *Lite summary of [Money Movement Flows & Orchestration | Formance Platform](/platform/flows). Request with `Accept: text/markdown` for this view.* --- title: "Security, Compliance & Trust | Formance Platform" description: "How Formance secures money-movement infrastructure: SOC 2 Type II, ISO 27001, DORA, encryption, granular access control, and an immutable audit trail." canonical: "https://www.formance.com/platform-security" slug: platform-security type: page-lite updated: "2026-06-29T15:04:46.645Z" --- *_SECURITY/* # Security by construction Your core financial infrastructure has to be safe, audited and reliable. Formance is built — and independently attested — to meet that bar. How Formance secures money-movement infrastructure: SOC 2 Type II, ISO 27001, DORA, encryption, granular access control, and an immutable audit trail. ## Page sections ## Section 1: logoStrip _TRUSTED BY TEAMS MOVING MONEY/ --- ## Section 2: secCompliance *_COMPLIANCE/* ### Independently attested SOC 2 Type II, ISO 27001 and DORA — every certification is verified by independent auditors and published in our trust center. --- ## Section 3: secPillars *PILLARS* ### Security at every layer *ENCRYPTION* Data is encrypted in transit (TLS 1.2+) and at rest (AES-256). Encryption keys are managed and rotated through a dedicated KMS, isolated per environment. ### Encrypted end to end *INFRASTRUCTURE* Workloads run in isolated, access-controlled environments with continuous monitoring. Availability and incidents are tracked publicly on our status page. ### Isolated, resilient infrastructure *ACCESS* Authenticate with OAuth 2.0, JWT and OIDC. Scope every token, enforce least-privilege roles (RBAC), and connect your own SSO. ### Granular access control *AUDITABILITY* The ledger is append-only and immutable. Every balance is the replayable sum of a tamper-evident transaction log — a complete audit trail behind every number. ### Auditable by design *OPEN SOURCE* The core ledger is open source. Inspect the code, self-host, and keep lifetime access — no black box at the center of your money movement. ### Open by default *ASSURANCE* Independent penetration tests run on every release, so regressions surface before they ship — not after. ### Tested every release --- ## Section 4: secDisclosure *_RESPONSIBLE DISCLOSURE/* ### Report a vulnerability Data security is a top priority, and we believe skilled researchers help identify weaknesses in any technology. If you believe you have found a vulnerability in Formance, please notify us — we will work with you to resolve it promptly. --- ## Section 5: secFaq *FAQ* ### Security, answered **CERTIFICATIONS** Formance is SOC 2 Type II and ISO 27001 certified and DORA-compliant. Current reports are available in our trust center. **DATA RESIDENCY** Choose where your data lives. Workloads and storage can be pinned to a region to meet residency and regulatory requirements. **ENCRYPTION** All traffic is encrypted with TLS in transit and AES-256 at rest. Encryption keys are isolated per environment and rotated regularly. **ACCESS** Access uses OAuth 2.0, JWT and OIDC with least-privilege RBAC. You can bring your own SSO and scope tokens to the minimum needed. **INCIDENTS** Platform availability and incidents are published in real time on status.formance.com, with a full incident history. **DISCLOSURE** Found a vulnerability? Our responsible-disclosure process gives researchers a direct channel and defined remediation timelines. --- ## Section 6: secCta *_GET STARTED/* ### Build on infrastructure you can trust Atomic, auditable and independently attested — see exactly how Formance secures your money movement. --- *Lite summary of [Security, Compliance & Trust | Formance Platform](/platform-security). Request with `Accept: text/markdown` for this view.* --- title: "Payments & Banking Connectivity | Formance Platform" description: "Connect Stripe, Adyen, Wise and dozens of banks behind a single API. Normalize payments, balances and payouts into one consistent data model." canonical: "https://www.formance.com/platform/connectivity" slug: platform-connectivity type: page-lite updated: "2026-07-22T11:08:32.186Z" --- *_CONNECTIVITY/* # Every rail, one model Connect PSPs and banks behind a single API. Normalize payments, balances, and payouts into one consistent data model. Connect Stripe, Adyen, Wise and dozens of banks behind a single API. Normalize payments, balances and payouts into one consistent data model. ## Page sections ## Section 1: connIngestion *_AT SCALE/* ### Ingest millions of payments in real time. Captures, refunds and payouts from 120+ connectors stream into one normalized feed — reconciled, deduplicated and ledgered as they land. Watch throughput, success rate and latency across every provider, live. --- ## Section 2: connConnectors *_CONNECTORS/* ### Dozens of connectors, ready to go #### Cards, banks, FX and wallets. Plug into the providers you already use. Each connector maps native events into the same payment, balance and payout primitives. --- ## Section 3: connCapabilities *_CAPABILITIES/* ### One capability surface, every connector #### Accounts, balances, payments, payouts and webhooks. Every connector — open-source (CE) or licensed (EE) — resolves to the same normalized payments-v3 surface. You know exactly what a PSP exposes before you build, and switching providers never changes your contract. --- ## Section 4: connUnifiedModel *_UNIFIED MODEL/* ### One model across providers #### Stop writing per-provider glue. Stripe, Adyen, Wise and dozens of banks collapse into a single normalized schema. Write your logic once; switch or add providers without rewrites. --- ## Section 5: connPaymentSchema *_ONE SCHEMA/* ### One payment shape, every provider. Stripe, Adyen, Wise or a bank — every payment comes back in the same normalized shape: id, provider, type, amount, asset, status. Query once, paginate with standard headers, and stop branching on provider-specific quirks. --- ## Section 7: connSync *_SYNC/* ### Payments & payouts in sync #### Internal orders matched to provider refs. Every internal order is linked to its provider reference and kept in sync as statuses change — so your ledger and your PSPs always agree. --- ## Section 8: connNormalized *_NORMALIZED/* ### One normalized stream #### Inbound and outbound, unified. Captures, refunds, payouts and credits from every provider land as one typed event stream — already mapped onto your ledger accounts. --- ## Section 9: connFaq *FAQ* ### Questions, answered **PROVIDER COVERAGE** Cards, banks, FX and wallets map to the same payment, balance and payout primitives. Adding a provider does not change your application logic. **NORMALIZATION** Each connector translates native provider events into one typed schema. You read captures, refunds and payouts the same way regardless of the source. **SYNC GUARANTEES** Every internal order is linked to its provider reference and updated as statuses change, so your ledger and your PSPs never silently disagree. **ADDING A PROVIDER** New connectors plug into the existing model. Switching or adding a provider is a configuration change, not a rewrite. **FAILURE HANDLING** Connector errors surface as typed events with the original provider payload attached, so you can replay or reconcile without guessing. --- ## Section 10: connCta *_GET STARTED/* ### Connect every rail behind one model Normalize PSPs and banks into one consistent payment, balance and payout model. --- *Lite summary of [Payments & Banking Connectivity | Formance Platform](/platform/connectivity). Request with `Accept: text/markdown` for this view.* --- title: "Programmable Ledger for Engineers | Formance Platform" description: "A double-entry programmable ledger built for engineers: atomic, immutable, and reconciled by construction. Model any money movement in Numscript." canonical: "https://www.formance.com/platform/ledger" slug: platform-ledger type: page-lite updated: "2026-07-22T11:07:57.975Z" --- *_LEDGER/* # A programmable ledger for money A double-entry ledger built for engineers — atomic, immutable, and reconciled by construction. A double-entry programmable ledger built for engineers: atomic, immutable, and reconciled by construction. Model any money movement in Numscript. ## Page sections ## Section 2: ledgerColored *ASSET COLORING* ### Fungible by default. Colored on demand. Pool client money as one fungible balance, or color each unit by its funding source to trace provenance down to the account — same ledger, same accounts, one toggle. --- ## Section 3: ledgerNumscript *_NUMSCRIPT/* ### Money as code #### Model any movement with Numscript. Describe complex money movements — splits, fees, holds — in a purpose-built DSL. Every transaction is atomic: it either commits in full or not at all. --- ## Section 4: ledgerDoubleEntry *_DOUBLE-ENTRY/* ### Balanced by construction #### Every posting nets to zero. Debits always equal credits. The ledger enforces double-entry accounting natively, so your books can never silently drift — no end-of-day surprises. --- ## Section 5: ledgerAccounts *_ACCOUNTS/* ### Multi-asset, multi-account #### Transactions in, balances out. Open unlimited accounts and hold any number of assets in parallel. Every transaction updates balances instantly — query any account, in any currency, at any point in time. --- ## Section 6: ledgerLog *_LOG/* ### An immutable, queryable log #### Every entry, forever. The ledger is an append-only log. Query balances and history at any point in time, with a complete and tamper-evident audit trail behind every number. --- ## Section 7: ledgerBulk *_BULK PROCESSING/* ### Batch operations, commit in a single call. The _bulk endpoint accepts a stream of ledger actions and processes them atomically, sequentially, or in parallel. Stage thousands of postings — idempotent by key — and let the ledger commit them in one round-trip. --- ## Section 8: ledgerAggregations *_AGGREGATIONS/* ### Every segment is an axis. One address space, three questions. Sum everything under a prefix, slice one state across every user, or drill into a single user's subtree — the structure you put in the address is the query language, computed where the postings live. --- ## Section 9: ledgerSharding *_SHARDED BY DESIGN/* ### Group ledgers into buckets. Scale sideways. Each bucket isolates throughput and storage, so you can run thousands of independent ledgers — per product, per region, per tenant — without coupling them operationally. Add ledgers inside a bucket, add buckets as you grow. --- ## Section 10: ledgerFaq *FAQ* ### Questions, answered **DOUBLE-ENTRY** Debits always equal credits. The ledger enforces double-entry natively, so balances can never silently drift. **IMMUTABILITY** Postings are append-only. History is never rewritten; you query balances and entries as of any point in time. **ATOMICITY** Each Numscript transaction commits in full or not at all — splits, fees and holds either all apply or none do. **MULTI-ASSET** Hold any number of assets across unlimited accounts in parallel. Balances update instantly, per asset and per account. **PERFORMANCE** The ledger sustains high transaction throughput while keeping the audit trail complete and queryable. --- ## Section 11: ledgerCta *_GET STARTED/* ### Build on a ledger that never drifts Atomic, immutable, double-entry by construction — modeled in Numscript. --- *Lite summary of [Programmable Ledger for Engineers | Formance Platform](/platform/ledger). Request with `Accept: text/markdown` for this view.* --- title: "Ledger Reconciliation for Fintech | Formance Platform" description: "Continuously compare ledger balances against your payments pool. The moment a day drifts, the gap is surfaced—not discovered weeks later at close." canonical: "https://www.formance.com/platform/reconciliation" slug: platform-reconciliation type: page-lite updated: "2026-07-22T11:08:47.998Z" --- *_RECONCILIATION/* # Internal equals external Match your Ledger against your Payments connectors and pooling accounts in real time — catch discrepancies the moment they appear. Continuously compare ledger balances against your payments pool. The moment a day drifts, the gap is surfaced—not discovered weeks later at close. ## Page sections ## Section 2: reconDrift *_DRIFT/* ### Catch drift instantly #### Ledger vs Payments pool, side by side. Compare your Ledger balances against your Payments pooling balances continuously. The moment a day drifts, the gap is surfaced — not discovered weeks later at close. --- ## Section 3: reconTemporal *_TEMPORAL/* ### Reconcile as of any date #### Bi-temporal by design. Pick a point in time and reconcile your Ledger against your Payments pool exactly as they stood then. Bi-temporal history means a late-arriving transaction never rewrites a past close — the books always agree at every date. --- ## Section 4: reconAudit *_AUDIT/* ### A full audit trail #### Every match, drift and resolution logged. Reconciliation produces an immutable trail: what matched, what drifted, and how it was resolved — ready for finance, audit and compliance. --- ## Section 5: reconPolicies *_POLICIES/* ### Reconciliation policies #### Each ledger account, paired to its payments source. Declare policies that bind a Ledger account to a Payments pool, then track them per policy and per asset. Equal balances mean your books and the outside world agree — any gap is flagged as drifting. --- ## Section 6: reconAccount *_ACCOUNT-BASED/* ### Reconciliation · account-based #### One invariant, checked continuously. Instead of chasing every transaction, account-based reconciliation proves a single relationship: for a given asset, the sum of your ledger accounts must equal the balance held in the external cash pool. As long as the totals agree, your books match the outside world — the instant they diverge, the gap is flagged. --- ## Section 7: reconFaq *FAQ* ### Questions, answered **DRIFT DETECTION** Ledger balances are compared against Payments pooling balances continuously. A gap is surfaced the moment it appears, not at close. **TEMPORAL** Reconcile as of any date. Bi-temporal history means a late-arriving transaction never rewrites a past close. **POLICIES** A policy binds a ledger account to a payments pool. Matches and gaps are tracked per policy and per asset. **AUDIT TRAIL** Every match, drift and resolution is logged immutably — ready for finance, audit and compliance. **RESOLUTION** Drifts carry their context — amounts, references, provider fees — so you resolve the real cause instead of forcing a balance. --- ## Section 8: reconCta *_GET STARTED/* ### Prove your books match the outside world Continuous reconciliation between your Ledger and your Payments pools, with a full audit trail. --- *Lite summary of [Ledger Reconciliation for Fintech | Formance Platform](/platform/reconciliation). Request with `Accept: text/markdown` for this view.* --- title: "Contact the Formance Team | Sales & Support" description: "Get in touch with Formance for product questions, partnerships, or support. Talk to our team about programmable financial infrastructure." canonical: "https://www.formance.com/contact" slug: contact type: page-lite updated: "2026-07-23T09:35:41.277Z" --- *CONTACT* # Get in touch A question, a partnership, or anything that is not a demo request send us a message and we will get back to you. Looking for a product walkthrough? Book a demo instead. # Connect with our team Get in touch with Formance for product questions, partnerships, or support. Talk to our team about programmable financial infrastructure. ## Page sections ## Section 1: logoStrip _TRUSTED BY TEAMS MOVING MONEY/ --- *Lite summary of [Contact the Formance Team | Sales & Support](/contact). Request with `Accept: text/markdown` for this view.* --- title: Privacy Policy description: "How Formance collects, uses and protects your personal data, your rights, and our data-processing practices under GDPR." canonical: "https://www.formance.com/privacy-policy" slug: privacy-policy type: page-lite updated: "2026-06-26T10:20:04.119Z" --- *LEGAL* # Privacy Policy # Privacy Policy How Formance collects, uses and protects your personal data, your rights, and our data-processing practices under GDPR. ## Page sections ## Section 1: textBlock Last update: 15 September 2023 We attach great importance to the protection of your personal data and take great care to ensure compliance with the protective provisions relating to privacy and the processing of personal data, in particular European Regulation n°2016/679 of 26 April 2016 on the protection of individuals with regard to the processing of personal data and on the free movement of such data and Law n°78-17 of 6 January 1978, known as the "Data Protection Act", as amended in 2018 (the "Legislation in Force"). We invite you to carefully read this privacy policy (the "Policy"), which contains important information on how we collect, use and communicate some of your personal data that you send to us in order to meet your needs but also to optimise and improve the quality of the services we offer you. ‍For the purposes of these Terms of Use, "you", "your" or "the User" means the natural person whose personal data is collected for processing hereunder and who is a "data subject" within the meaning of the Applicable Law, as defined below :‍ "User Account" means the account created by the User on the Solution enabling him/her to access the Service. ## 1. WHO ARE WE? The Formance solution (the "Solution"), available at the URL **https://formance.com**, which enables its users to build and track custom money flows for their platform or application (the "Service"), as well as the showcase website available at the URL **www.formance.com** (the "Showcase Website"), are provided to you by the company GOLDILOCKS, simplified joint stock company with a single shareholder, registered under the Paris trade and companies register, No. 898 531 371, with its registered office located at 9, rue des Colonnes, 75002 PARIS - France (hereinafter referred to as "FORMANCE"). You can contact our Data Protection Officer at the following email address: **support@formance.com**. When you visit the Showcase Website, for the purpose of informing you about the Solution and the Service, we act as a "data controller" within the meaning of the Legislation in force. In the context of your use of the Service through the Solution, we are also acting as a "data controller" within the meaning of the Legislation in force. You can contact our Data Protection Officer at the following email address: **support@formance.com** ‍When you visit the Showcase Website, for the purpose of informing you about the Solution and the Service, we act as a "data controller" within the meaning of the Legislation in force. In the context of your use of the Service through the Solution, we are also acting as a "data controller" within the meaning of the Legislation in force. ## 2. PERSONAL DATA COLLECTED ### **2.1 Information provided by the User** When you use the Solution or browse the Website Vitrine, some of your personal data such as your identification data (name, first name, gender, date of birth), your contact details (email address, postcode), your IP address, your location data, and your browsing history on the Solution or the Website Vitrine may be processed. We also reserve the right to keep an archive of all contacts you make with us. ### **2.2 Information automatically collected** We may monitor your use of the Showcase Website, the Service and the Solution through cookies and other similar tracking devices. For example, we may track the number of times you use the Showcase Website, the Service or the Solution, the data traffic on the Solution, your IP address, your location data and your browsing history. This information helps us to determine the profile of our users and allows us to establish statistics, traffic volumes and use of the various elements of the Solution and the Showcase Website in order to improve their ergonomics and interest. When using cookies, the data will be aggregated, which means that we will not be able to identify you individually. For more information on the use of cookies, please see the dedicated section below. ### **2.3 Information provided by third parties** As part of the Services, we may receive information about you from third parties who hold personal data about you that you have indicated to us, including third party payroll, payment or other providers connected to the Solution. This information will be automatically added to the information collected about you, in order to best meet your needs and to optimize and improve the quality of the services we offer you. ## 3. HOW WE USE YOUR PERSONAL DATA We use your personal data as a data controller for the following purposes • your use of the Website; • to manage your enquiries; • sending you our newsletter; • statistical analysis; • prevention and detection of fraud, malware and management of security incidents; • your use of the Service and the Solution; • identifying you or the User Accounts you have created to use our Services; • manage enquiries or support requests in connection with your use of the Solution. • improve the Service, the Solution and our Website; In accordance with the Legislation in force, the processing of your personal data is based on at least one of the following legal bases your consent to this processing; the proper performance of the contractual relationship between you and us or the performance of pre-contractual measures at your request; compliance with Applicable Legislation; our legitimate interest in selling our products and services and improving them or maintaining the Website or the Solution.‍ ## 4. HYPERTEXT LINKS The Solution and the Showcase Website may contain hypertext links to the websites of our partners and third parties (in particular social networks and partner merchants). Please note that if you follow these links, the websites and services provided will be governed by their own terms of use and privacy policies. We cannot be held responsible if their terms of use and privacy policies do not comply with current legislation. We advise you to read the privacy policies and terms of use applicable to these websites before providing your personal data and using these websites. ## 5. DISCLOSURE OF YOUR PERSONAL DATA For the purposes set out in section 3, we may transfer some of your data to : • IT service providers, in order to host your data, maintain our systems, the Showcase Website, our services, the Solution and the Service, or monitor the performance of the Showcase Website, the Service, the Solution and the User experience; • third parties holding personal data about you, at your request and in the context of the execution of the Services; • third parties to whom the User has given consent to access the personal data we collect; • commercial partners, with your consent, so that they can offer you their services; • business partners, after anonymisation of your data for statistical purposes; • our advisers, such as our lawyers and accountants, and any potential purchaser and their advisers, and new transferees or beneficiaries of the business if our business is sold or merged with another company; • representatives of law enforcement, judicial or administrative authorities or other authorised third parties, subject to our ethical obligations regarding confidentiality, in response to a request for information if we believe that the disclosure of such information is lawful or required by Applicable Law. ## 6. SECURE STORAGE OF YOUR DATA We use appropriate technical and organisational measures to protect your personal data, for example • access to your User Account is controlled by a unique password and user name; • we store your personal data on secure servers. While we are committed to using our best efforts to protect your personal data, you acknowledge that the use of the Internet is not completely secure and that, as such, we cannot guarantee the security or integrity of any personal data provided by you or provided to you via the Internet. ## 7. TRANSFERS OUTSIDE OF THE EUROPEAN UNION Your personal data is processed within the European Union, unless we notify you of the transfer of your personal data outside the European Union. ## 8. YOUR RIGHTS You have the right to access, rectify or delete your personal data, to limit the processing of your personal data, to object to the processing of your personal data and to have your data ported. You also have the right to set out instructions regarding the retention, erasure and communication of your personal data after your death. Where processing is based on your consent, you also have the right to revoke it. You may exercise these rights at any time by sending your request, together with proof of identity, to the email address given at the beginning of this Policy or by post to the following address: 9 Rue des Colonnes, Paris 75002. Any request should specify the personal data you wish to access, rectify, delete or replace or whose processing you wish to limit or invoke portability. Your User Account information may be requested to facilitate the processing of your request. We reserve the right to ask you for proof of your identity to verify its accuracy before exercising these rights. You may also lodge a complaint with the Commission Nationale de l'Informatique et des Libertés if you consider that the processing of your personal data infringes your data protection rights. ## 9. DATA RETENTION PERIOD Your data will be retained for a period not exceeding that necessary to fulfill the purposes set out in this Policy. If your data is no longer required for the purposes set out in this Policy, it will be routinely deleted unless it is necessary to keep it for longer: • to ensure compliance with legal, accounting and tax retention obligations, i.e. 10 years ; • for the conservation of evidence during the applicable limitation periods, i.e. 5 years; f• or commercial prospecting purposes, i.e. 3 years from the end of our commercial relationship with you or from our last contact with you. Furthermore, if we find that your User Account has not been used for more than 2 years, we will delete your personal data. ## 10. USE OF COOKIES ### **10.1. Our cookies** A "cookie", also known as a "tracker" or "cookie" is a small text file containing data that is stored on a terminal (computer, tablet, smartphone...) when you browse a website. We use cookies and other similar tracking devices, such as tags and web beacons on our Solution and our Showcase Website to: • recognise you when you use the Solution, for example to speed up your access to the Service by allowing you to log in automatically to your User Account each time you log in to the Solution; • obtain information about your preferences, your online movements and your use of the Internet in order to produce statistics and improve the ergonomics of our Showcase Website and the Solution; • to conduct statistical research and analysis to improve the content of the Website, the Service and our services and to help us better understand your expectations and needs as a prospect or User; • to make your online experience more functional and enjoyable. If you have accepted the storage of cookies on your browser, the cookies embedded in the pages and content you have consulted may be stored temporarily in a dedicated space in your browser. They will only be readable by the sender. This information will not be stored for more than 13 months. ### **10.2. Cookies provided by third parties** We work with third party suppliers such as Google who may also install cookies on the Solution or the Showcase Website for anonymised statistical purposes. These third parties are responsible for these cookies installed on our Solution or Showcase Website. If you need more information, we invite you to consult the privacy policies of these third parties, which are available on their website. ### **10.3 Deactivation of cookies** If you are not satisfied with the use of cookies, you can easily delete them by accessing your browser's cookies folder. You can also set your browser to block cookies or to send a warning message before a cookie is placed on your computer. For more information about cookies and how to disable them, please visit **www.aboutcookies.org** or **www.allaboutcookies.org**. ## Contact us to exercise your rights under GDPR. At Formance, we are committed to protecting the privacy of our customers and their end users. You can find our form for Data Requests **https://gdpr.formance.com** or you can also email us at compliance@formance.com with any questions or for more information on this topic. This allows you to exercise your rights under GDPR regulations. --- *Lite summary of [Privacy Policy](/privacy-policy). Request with `Accept: text/markdown` for this view.* --- title: Terms of Service description: The terms governing your subscription to and use of the Formance platform and its associated services. canonical: "https://www.formance.com/terms-of-service" slug: terms-of-service type: page-lite updated: "2026-06-26T10:20:38.729Z" --- *LEGAL* # Terms of Service # Terms of Service The terms governing your subscription to and use of the Formance platform and its associated services. ## Page sections ## Section 1: textBlock ## Preamble The Terms of Service (hereinafter referred to as the "ToS") apply to any subscription to the FORMANCE Solution (hereinafter referred to as the "Solution") and associated services (hereinafter referred to as the "Services") entered in force between the Partner and GOLDILOCKS, simplified joint stock company with a single shareholder, registered under the Paris trade and companies register, No. 898 531 371., with its registered office located at 9, rue des Colonnes, 75002 PARIS - France (hereinafter referred to as "FORMANCE"). FORMANCE offers a programmatic Solution enabling fintech applications (hereinafter referred to as "Application") and/or software (hereinafter referred to as "Software") and marketplaces (hereinafter referred to as "Platform") to build, monitor and track their money flows, controlled by their Payment Service Providers (hereinafter referred to as "PSP") providing them payment services (hereinafter referred to as "Payment Services") according to their own Master Payment Services Agreement (hereinafter referred to as "Master Payment Services Agreement"). The Solution is provided via API. The partner identified within the Particular Conditions wished to be provided with the Solution and associated Services (hereinafter referred to as "Partner"). FORMANCE sent the Partner a Proposal (hereinafter referred to as "Proposal"), which completes the Particular Conditions above (hereinafter referred to as "Particular Conditions"), The PARTNER and FORMANCE are hereinafter referred to as, individually the "Party", and, together the "Parties". ## Important notice ANY SUBSCRIPTION TO THE FORMANCE SOLUTION AND ASSOCIATED SERVICES IMPLIES THE ACCEPTANCE BY THE PARTNER OF THESE TERMS OF SERVICE. ## ARTICLE 1. CONTRACTUAL DOCUMENTS The Agreement consists of the following contractual documents, listed in order of precedence: • The Proposal; • The Particular Conditions; • The Terms of Service in force, • The Appendixes (Pricing and Service Level Agreement). In the event of a contradiction between one or more provisions of the contractual documents forming part of the Agreement, the provisions of the higher-ranking documents shall prevail. ## ARTICLE 2. PARTNER INFORMATION As part of FORMANCE duty to inform and advise under French law, the Solution was presented in detail to the Partner, in particular by means of a documented commercial presentation. The Partner acknowledges that he has verified the suitability of the offer and the Services to its needs and constraints and that it has received from FORMANCE the necessary information and advice to enter into this Agreement knowingly. ## ARTICLE 3. ACCEPTANCE AND MODIFICATION OF THE AGREEMENT ### **3.1. Acceptance of the Agreement** The Agreement apply to any Partner subscription to the Solution and Services. The Partner undertakes to read these Agreement carefully and to accept it before subscribing to and using the Solution. ### **3.2. Modification of the Agreement** FORMANCE may modify this Agreement at any time. These modifications will be notified to the Partner on a durable medium at least thirty (30) days before the changes come into force. In the event of substantial modifications hereto, the following hypotheses should be distinguished: Either the Partner consents to the said substantial modifications, in which case they shall automatically come into force on the date provided for in the notification, or Either the Partner refuses the substantial modifications, in which case the Partner may terminate all or part of the Agreement in advance, without charge, by sending a registered letter with acknowledgement of receipt within thirty (30) days of the notification. In this case, the Partner undertakes to pay FORMANCE all the sums corresponding to the use of the Solution and the Services up to the date on which the termination takes effect, where applicable calculated on a pro rata basis of the initial commitment and the period elapsed. It is specified that, in this case, the termination will take effect on the day the amended Terms of Service come into force. ## ARTICLE 4. DURATION AND TERMINATION ### Article 4.1 Duration of the Agreement The Agreement shall come into force upon signature by the last of the Parties for the period defined within the Particular Conditions. ### **Article 4.2 Suspension** FORMANCE may suspend the Agreement by operation of law, without compensation to the Partner, and without prior notice, in the following cases: In the event of non-cooperation and/or disloyalty found by FORMANCE, and if there is an urgent need to stop the conduct concerned; In case of use of the Solution for illegal or unlawful purposes; In the event of a breach of the commitments made by the Partner under the Agreement. The Partner shall be notified of this decision by registered letter acknowledgement of receipt. The suspension may be lifted within a maximum of fifteen (15) working days from the receipt by FORMANCE of a registered letter with acknowledgement of receipt justifying, with proof, that the cause of the suspension notified to the Partner has been put an end to. This lifting is, in any case, subject to the acceptance of FORMANCE. ### Article 4.3 Termination #### **4.3.1. Termination following suspension** Any suspension may lead to termination if Partner does not respond satisfactorily to the grievances notified to it within fifteen (15) days of the first day of Services suspension. #### **4.3.2. Termination for default** In the event of a serious or repeated breach by one Party of at least one of its obligations hereunder, this Agreement may be terminated by the other Party. It is expressly agreed that such termination shall take place as of right, thirty (30) days after a formal notice to perform has been sent and has remained without effect. The formal notice, which must indicate the grievances complained of and the obligations allegedly not complied with, shall be sent by registered letter with acknowledgement of receipt. #### **4.3.3. Termination for convenience** Cases where the Agreement is concluded for an indefinite period Where the Agreement is concluded for an indefinite period, either Party may terminate it for convenience by sending the other Party a registered letter with acknowledgement of receipt specifying the reason for the termination. Subject to what has been planned within the Particular Conditions, the Agreement shall be terminated sixty (60) days after receipt of the said letter by the Party to whom it is addressed if the period during which the Agreement has been performed is less than or equal to three (3) years. The Agreement will be terminated automatically six (6) months after receipt of the said letter by the receiving Party when the period during which the Agreement has been performed is greater than three (3) years. Cases where the Agreement is concluded for a fixed term Where the Agreement is concluded for a fixed term, each Party shall be bound to perform it until the end of the commitment period specified in the Particular Conditions. Subject to what has been planned within the Particular Conditions, each Party may nevertheless oppose the tacit renewal of the Agreement by terminating it by sending the other Party a registered letter with acknowledgement of receipt in the delay defined within the Particular Conditions. In the event of termination in accordance with the above provisions, the termination will take effect on the anniversary date of the Agreement. ### **4.3.4. Other reasons for termination** The Agreement is entered into intuitu personae, in consideration of the qualities of the Partner and the existing relationship between FORMANCE and the Partner. Consequently, FORMANCE may terminate the Agreement by operation of law in the event of a takeover of the Partner by a third party or the transfer of the Partner's business to a third party. ### Article 4.4 Consequences of the Agreement expiration The Partner acknowledges that the expiration, cancellation or termination of the Agreement for any reason whatsoever shall result in the immediate termination of the rights granted to the Partner under the Agreement. Accordingly, the Partner agrees and acknowledges that upon expiration of the Agreement for any reason whatsoever, it shall have no further right to access or use the Solution and Services. Upon termination of the Agreement for any reason, the Partner agrees to: Return to FORMANCE all types of information and/or data to which it has access in the context of the Agreement, regardless of the format or medium, (in this included Personal Data (defined below), Metadata (defined below), financial data, operators data, customers data, Partners data, and/or strategic, technical, professional, administrative, commercial, legal, accounting data, etc. (hereinafter referred to as the "Data")) and as well as all documents of any kind, drawings, concepts, manufacturing secrets, Know-How, information systems, software, transmitted or brought to the knowledge of a Party under the Agreement, regardless of the form and/or media used (hereinafter referred to as "Confidential Information"); Destroy any copies of the documents and Data transmitted under the Agreement, including Confidential Information, that are still in its possession; Pay all outstanding sums to FORMANCE, if necessary calculated pro rata to the initial commitment and the period elapsed. The provisions of the Agreement relating to intellectual property, confidentiality, liability, and Personal Data shall survive termination of the Agreement for an additional five (5) years unless otherwise expressly provided by law or regulation. ## ARTICLE 5. TECHNICAL REQUIREMENTS In order to use the Solution, the Partner undertakes to integrate its Application / Software and/or Platform with the API of FORMANCE in accordance with the instructions transmitted by FORMANCE to this effect. Otherwise, the Partner acknowledges that it will not be able to access the Solution or the Services. Partner acknowledges that all of the requirements detailed in this section are at Partner's expense. ## ARTICLE 6. DESCRIPTION OF SERVICES Subject to having subscribed to the Solution and to the option for which Partner subscribed (see Particular Conditions), the Partner may benefit from the Services detailed below. ### **6.1. Provision of the Solution** The Solution allows Partner, notably thanks to "**Numscript**", a built-in and low-code language, to build, supervise and track all its payment inflows and outflows, controlled by their Banking and Payment Providers.  To this end, FORMANCE notably provides the "**FORMANCE Ledger**", which makes it possible to establish the origin of a transaction and its final destination regardless of the number of intermediate steps between, by mirroring this transaction into a "**Ledger Transaction**".  A Ledger Transaction is the “mirror” of a transaction sent by the Client, recorded by the FORMANCE Ledger. Once it has been recorded within the FORMANCE Ledger, a Ledger Transaction provides a minimum of four pieces of information: source of the transaction, destination, type of asset and amount. ### 6.2. Interconnexion with Payment and Banking Providers For the performance of the Services, the Partner can connect the Solution to its chosen Banking or Payment provider. This connection is made thanks to APIs provided by FORMANCE and/or the Provider(s).  The Banking and Payment Services related to the Partner’s payment flows are provided exclusively by the Provider. Hence the Banking and Payment Services are ruled by the Master Provider Services Agreement concluded between the Partner and its Provider(s).  This Agreement does not affect, in any way, the various Providers Master Payment Services Agreement.  FORMANCE cannot guarantee its API can necessarily be interfaced with the Provider chosen by the Partner. However, FORMANCE guarantees the use of the Solution even in the event of interoperability or incompatibility between the FORMANCE's API and the Provider. In the event where FORMANCE would have to develop a new API in order to connect its Solution to the Partner’s PSP, FORMANCE shall make its best effort to develop it in a short period of time. ### 6.3. Hosting By default, the SaaS Service is hosted by Amazon Web Services. The information and contractual conditions are available at any time on request from the Partner to FORMANCE. At the Partner's request, FORMANCE may provide alternative hosting options, especially in cases where the Partner would like to self-host a part or the entirety of the Formance Solutions. Any additional services to be performed by FORMANCE shall be subject to a separate agreement between the Parties. ### 6.4. Evolution of Services FORMANCE reserves the right to freely develop the Services, at its sole discretion, in particular in order to improve the existing Services. The Partner acknowledges that the signing of the Agreement does not in any way give it the right to demand an upgrade of the Services or to obtain the provision of new Services. ## ARTICLE 7. OBLIGATIONS OF THE PARTIES ### 7.1. Obligations of the Partner In this Agreement "Metadata" means: the Data, including Personal Data, related to payments made by end-users through the Application, Software and/or Platform and collected by the API within the framework of the Services in order to generate the pay outs (including notably the date and amount of transactions and of transfer orders). Partner agrees to: • Interconnect its Application / Software and/or Platform to the API according to the instructions transmitted by FORMANCE to this effect; • Implement all security measures necessary to protect Data and Confidential Information in accordance with the state of the art in its profession; • Share, in real time, with FORMANCE any information and/or Data necessary for the proper execution of the Services and in particular any Data and/or information required by FORMANCE to provide the Services. The list of required information and/or Data will be transmitted to the Partner within the instructions; • Especially share, in real time, with FORMANCE any Metadata necessary for the proper execution of the Services and/or required by FORMANCE to provide the Services; • Verify the compatibility of the various payment service providers with each other, in order to allow FORMANCE to provide the Services; • Pay the Price for the Services as described in Section 9 hereafter. The Partner acknowledges that FORMANCE has no control over the accuracy and completeness of the information/Data and/or Metadata collected from the Partner. Consequently, the Partner undertakes to provide FORMANCE with accurate, complete and up-to-date information/Data and/or Metadata. Failing this, FORMANCE will not be able to provide the Services to the Partner, which the Partner expressly acknowledges and accepts. In any case, the Partner acknowledges that FORMANCE cannot be held responsible for the generation of a payment operation due to the provision by Partner of incorrect, incomplete or out-of-date information/Data and/or Metadata. The Partner accepts and expressly acknowledges that it is solely responsible for the use of the Solution. When using the Solution, the Partner undertakes not to undermine public order and to comply with the laws and regulations in force, to respect the rights of third parties and the provisions of this Agreement. The Partner is obliged to: • Behave in a fair and lawful manner towards FORMANCE and third parties; • Be honest and truthful in the information provided to FORMANCE and others; • To use the Solution in accordance with its purpose as described in these Agreement; • Not to divert the purpose of the Solution, in particular to commit crimes, misdemeanors or contraventions punishable by the penal code or any other law; • Respect the privacy of others and the confidentiality of exchanges; • Respect the intellectual property rights of FORMANCE concerning the elements of the Solution and, if applicable, the intellectual property rights of third parties; • Not to seek to undermine the meaning of Articles 323-1 and seq. of the French Penal Code regarding systems of automated data processing implemented on the Solution; • Not modify the information put online by FORMANCE or by a third party; • Not to provide Payment Services in an illegal manner; • Not disseminate data that will diminish, disrupt, slow down or interrupt the normal operation of the Solution. ### 7.2. Obligations of FORMANCE It is expressly agreed between the Parties that FORMANCE is subject to a general obligation of means and that it is not bound by any obligation of result or of reinforced means of any kind. #### 7.2.1. Availability It is understood between Parties that, for the understanding of the provisions below, the Solution doesn’t encompass the API provided by FORMANCE in order to connect the Solution to the PSPs interface. FORMANCE undertakes to do everything in its power to make the Solution accessible 24 hours a day, 7 days a week except: • In the case of force majeure or an event beyond the control of FORMANCE, • In the case of any breakdowns or maintenance interventions necessary for the proper functioning of FORMANCE; • In the case where the Solution could not be used because of an incompatibility between the Solution and the PSP’s interface. However, FORMANCE cannot be held responsible for disruptions, interruptions and anomalies that are not of its making and that affect, for example, transmissions via the Internet network and more generally via the communication network, regardless of their importance and duration. FORMANCE can’t be held responsible in the event where the Solution could not be used because of an incompatibility between FORMANCE’s API and the PSP chosen by the Partner. It is furthermore specified that FORMANCE reserves the right to temporarily interrupt the accessibility to the Solution or to suspend all or part of the Services for maintenance reasons, for the improvement and installation of new functionalities, for the audit of the proper functioning of the Solution or in case of malfunction or threat of malfunction. #### 7.2.2. Maintenance • “Anomaly": refers to the Blocking and Non-blocking Anomalies that may affect the Solution and/or the Services; • “Blocking Anomaly": refers to a malfunction that prevents the use of all or part of the essential functionalities of the Solution or the Services; • “Non-blocking anomaly": refers to all malfunctions other than those defined in the blocking anomalies, in particular those which prevent the normal use of all or part of the non-essential functionalities of the Solution or which can be bypassed. FORMANCE undertakes to do its best to make the technical corrections to be made to the Solution concerning the possible anomalies in relation to the applicable security standards. In this respect, it is specified that the anomalies are listed according to the nature of the dysfunctions noted: • FORMANCE will make its best efforts to correct any Blocking Anomaly or to put in place a workaround solution, within seventy-two (72) hours of its notification by the Customer; • FORMANCE will use its best efforts to correct any Non-Blocking Anomaly within five (5) working days from its notification by the Customer. • FORMANCE makes available to the Customers a Technical Support service during working hours, by email at: support@formance.com Any intervention resulting from a misuse by the Partner of the Solution or the Services may give rise to specific invoicing. #### 7.2.3. Safety & Security FORMANCE agrees to use its best efforts to: • Ensure logical and physical security of its information systems; • Minimize the risk of a security incident. ## ARTICLE 8. INTELLECTUAL PROPERTY ### 8.1 Intellectual property of FORMANCE The Partner expressly acknowledges the intellectual property rights of FORMANCE and, where applicable, its licensors to the Solution, its components and related elements and waives any right to contest these rights in any form whatsoever. The Solution, its components and related elements, including but not limited to trademarks, logos, slogans, graphic charts, graphics, photographs, animations, videos, software solutions and texts and any other content on the Solution, are the exclusive intellectual property of FORMANCE, subject to any part of the Solution that may be licensed as “Open Source” and may not be reproduced, used or represented without express authorization under penalty of legal action. The Partner acknowledges that, to these day, part of the Solution is coded under the Open Source MIT License, that is a permissive license enabling FORMANCE to commercialize its Solution as proprietary one. Hence, any representation or reproduction, total or partial, of the Solution and its contents, by any means whatsoever, without the prior express authorization of FORMANCE, is prohibited and will constitute an infringement punishable by the provisions of the code of intellectual property. In particular, FORMANCE expressly prohibits, by any means whatsoever, the adaptation, modification, decompilation, disassembly, combination of all or part of the Solution with another solution, copying, reproduction, transcoding or reverse engineering of all or part of the Solution as well as the identification of all or part of the source code, except the one that directly derives from the Open Source MIT License. ### 8.2. License to use the Solution FORMANCE grants the Partner a personal, non-exclusive, non-assignable and non-transferable right to use the Solution for the entire duration of the Agreement. This license is granted worldwide. The Partner may only use the Solution within the strict limits of these Agreement and for their own professional needs, to the exclusion of any other purpose. The right to use means the right to represent and implement the Solution in accordance with its purpose, in the form of an API, via a connection to an electronic communications network, to the exclusion of any other use of the Solution. It is specified that the Partner may not under any circumstances make the Solution available to a third party, in particular by granting a sub-licence for the use of the Solution, without the express, written and prior agreement of FORMANCE. The Partner undertakes not to adapt, modify, decompile, disassemble, identify the source code of the Solution, merge or combine said code with any other software, copy, reproduce, transcode, adapt or modify any of the software, including in particular through the intervention of a third party, except as expressly authorized by Article L.122-6-1 of the French Intellectual Property Code. Any other exploitation of the Solution, its components and its elements, is expressly excluded from the scope of the present license and cannot be carried out without the prior, written and express authorization of FORMANCE. Thus, the Partner prohibits itself from, in particular any use of the Solution which has the purpose or effect of infringing the intellectual property rights and/or know-how of FORMANCE on the Solution, including in particular any reverse engineering of the Solution. The Partner acknowledges that the license of use granted in the present article does not confer on them any property right of any nature whatsoever on the Solution and the elements that compose it, which are and will remain the exclusive property of FORMANCE and, if applicable, of its licensors. ### 8.3. Property of the Partner The Partner remains the owner of its Application, Software and/or Platform and the related content, namely its trademarks, logos and distinctive signs. For the execution of this Agreement, the Partner grants a free and non-exclusive license to FORMANCE to use, reproduce, represent, mention its logos, its brands, its corporate name as well as all visible distinctive signs for reference. This license will be valid for the entire duration of the present Agreement and for the whole world. ### 8.4. Know-how The Solution contains elements of FORMANCE's know-how, including its API, as well as methods, techniques and software allowing to provide the Services. The Partner accepts and acknowledges that with the exception of the right of use granted by the present document, the Agreement does not confer any right of any nature whatsoever on the know-how of FORMANCE of which it expressly prohibits itself any use or reuse in any manner whatsoever without the prior and express written authorization of FORMANCE. In particular, the Partner recognizes that the know-how of FORMANCE is strictly confidential and refrains from any disclosure of the latter. ## ARTICLE 9. FINANCIAL CONDITIONS ### Article 9.1 Price of the Services In return for the right of use granted and the Services provided, the Partner undertakes to pay FORMANCE the price of the Services as set out in the Particular Conditions and under the conditions set out herein. FORMANCE may modify the applicable prices, subject to the conditions set out in the Article 3 “Acceptance and modification”. Subject to what is stated in the Particular Conditions, the Price of the Services is proportional to the monthly volume of Ledger Transactions processed by the Solution. The Price of the Services as invoiced to the Partner shall take into account such changes, if any, and shall be the price to be paid by the Partner for the Services provided for the relevant period, which the Partner expressly accepts and acknowledges. ### Article 9.2. Billing of Services The Price for the Services will be invoiced to the Partner on the date defined within the Particular Conditions. Subject to what the Particular Conditions, the Partner undertakes to pay the invoices sent to it within thirty (30) days from the date of issue of the invoice. In the event of default or delay in payment, late payment penalties will be calculated as follows: Late fees = (amount incl. VAT of the invoice x Applicable legal rate for the semester) × (number of days late in the semester / 365). The Applicable Legal Rate is the interest rate applied by the European Central Bank to its most recent refinancing operation plus ten (10) percentage points. Late payment penalties are due on the day following the payment date indicated on the invoice, without any prior notice of default being required. The Partner who is in default of payment is automatically liable to pay FORMANCE a fixed indemnity for collection costs of forty (40) Euros. If the collection costs are higher than the amount of this fixed compensation, FORMANCE can ask for an additional compensation, on justification. In addition to the late payment penalties, the Partner's failure to pay may result in the suspension of the Service (see Article 4.2 above) until full payment of the amounts due. ## ARTICLE 10. LIABILITY & WARRANTY ### **10.1. Liability** It is reminded that the Partner may engage the responsibility of FORMANCE if it has previously notified the alleged breach by registered letter with acknowledgement of receipt and if FORMANCE has not responded within thirty (30) days of receipt of this notice. In any case, it is recalled that the responsibility of FORMANCE can only be sought in case of proven fault. In general, FORMANCE cannot guarantee that the Solution and/or the Services will generate an increase in revenue. FORMANCE declines all responsibility: • In case of incomplete, incorrect or outdated information, Data and/or Metadata provided by the Partner, its PSP, or the end-user of the Application, Software and/or Platform; • In case of error made by one or several PSP working with the Partners; • In the event where one or more PSPs would block the interconnection between their software solution and the Solution/FORMANCE API; • In the event where FORMANCE would no longer be allowed to provide its Services due to a change in banking regulations or their interpretation by the competent authorities; • In case of impossibility to temporarily access the Solution for technical maintenance operations or updating of the published information. The Partner acknowledges that FORMANCE cannot be held responsible in case of malfunctions or interruptions of the said transmission networks; • In case of virus attacks, illicit intrusion in an automated data processing system; • In case of abnormal use or illicit exploitation of the Solution by the Partner and/or a third party; • With respect to the accuracy, completeness or currency of the information, Data and/or Metadata used in connection with the Services; • In case of the Partner's identity theft; • In case of diversion of the Solution from its purpose by the Partner, in particular to commit illegal acts and/or acts punishable by the regulations in force; • In case of delay or non-performance of its obligations, when the cause of the delay or non-performance is related to a case of force majeure; • In the event of a foreign cause not attributable to FORMANCE; • In the event of inaccuracy, incompleteness or obsolescence of the information, Data and/or Metadata provided by the Partner to benefit from the Solution and the Services, and for all the prejudices suffered as a result of the above-mentioned characteristics; and • In the event of unlawful action by the Partner, or contractual non-performance by the Partner in connection with the provision of the FORMANCE Solution. • In the event of abnormal use or unlawful exploitation of the Services by the Partner, the Partner shall be liable for damages caused to FORMANCE and any other third parties and for the consequences of any claims or actions that may arise. It is reminded to the Partner that as the Solution includes “Numscript” which is a low code solution enabling the Partner to freely build its own payments flows and their general architecture, FORMANCE shall not be liable in the event where the Partner uses the Solution in an illicit way. Thus, it is the Partner responsibility to determine whether its use of the Solution implies to be granted with a banking licence or any equivalent. FORMANCE will not be liable for any consequential damages, such as, but not limited to, financial or commercial loss, loss of profit, commercial disturbance, loss of earnings, damage to a third party, or action brought by a third party against the Partner and the consequences thereof, arising out of or in connection with this Agreement. The Partner is solely responsible for any direct or indirect, material or immaterial damage caused by himself or one of his employees to FORMANCE or to third parties as a result of its use of the Solution or the Services. In any case, it is expressly agreed between the Parties that if the liability of FORMANCE were to be retained within the framework of the execution of the Agreement for the provision of Services, this liability would be limited, all damages and all claims combined, to the sums paid by the Partner under the Agreement over the last six (6) months. It is expressly agreed between the Parties that the provisions of this clause shall continue to apply even in the event of termination of the Agreement by a final court decision. ### **10.2. Warranty** #### **10.2.1 General principles** Each Party covenants and warrants to the other Party: • That it has the power and authority to enter into the Agreement, and that it will secure and maintain, during the course of the relationship, all necessary authorizations, if any, to perform its obligations; • That it owns, or has been granted the rights to use for the purposes of the Agreement, all intellectual property rights necessary to fulfill its obligations, subject to any part of the Solution that may be licensed as "Open Source" and in the latter case, that the "Open Source" license used gives it the right to market and/or license said parts of the Solution; • That it will perform its obligations under the Agreement in accordance with all applicable laws and with reasonable care and skill; • It will not do or omit to do anything that would cause the other Party to violate any applicable law or regulation; and • That it will not denigrate the other Party. #### **10.2.2 Peaceful possession warranty** In all cases, FORMANCE guarantees that the Solution does not constitute an infringement of an intellectual property right, or any form of unfair competition or parasite. Consequently, FORMANCE guarantees the Partner against any harmful consequences (in particular any conviction and the costs incurred in its defence) resulting from an action for infringement, unfair competition or parasitism by a third party. In the event where a ban on use the Solution is imposed as a result of an infringement action, the Partner must: • Promptly notify FORMANCE in writing of any alleged infringement; • Not make any admission of infringement without FORMANCE's prior written consent; • Allow FORMANCE to participate in the negotiations and proceedings at its own cost and expense; FORMANCE shall then, at its option and expense, either: • Obtain the right for the Partner to continue using the Solution; • Replace the infringing part with an equivalent element that is not the subject of an infringement action and that has the same functionality; • Modify the infringing part so as to avoid said infringement. These choices are at FORMANCE's sole discretion, notwithstanding the Partner's right to seek compensation for damages. It is agreed between the Parties that, without prejudice to the Partner's other rights under these Agreement, if none of the foregoing alternatives is reasonably practicable, FORMANCE will remove the infringing Solution and compensate the Partner, subject to the liability thresholds set forth hereabove. ## Article 11. FORCE MAJEURE FORMANCE cannot be held responsible if the non-execution or the delay in the execution of one of its obligations described in the Agreement results from a case of force majeure. ## ARTICLE 12. PERSONAL DATA In this Agreement, “Personal Data” shall have the same meaning than in GDPR regulation. ### **12.1. Data processing carried out by FORMANCE in its capacity as autonomous Data Controller** FORMANCE collects Personal Data about the Partner in order to: • Provide the Partner the Service; • Manage billing for Services; • Manage Partner's rights exercise requests; • To perform statistics in order to improve the Services. To learn more about data management and the rights that can be exercised, the Partner is invited to consult the FORMANCE Privacy Policy available on its website. ### **12.2. Data processing carried out by FORMANCE as a processor** The Partner expressly acknowledges that, with regard to the data processing carried out by means of the Solution and the Services, FORMANCE acts as a processor of the Partner. ## ARTICLE 13. CONFIDENTIALITY Each Party agrees to use the Confidential Information, directly or indirectly, in whole or in part, only for the strict performance of this Agreement. Any substantiated disclosure may result in liability, regardless of the cause of the disclosure. The confidentiality obligations set forth in this clause shall not apply to all or any portion of the Confidential Information to the extent that: • They were legally held by the receiving Party prior to their disclosure; • It has been lawfully disclosed to the receiving Party by a third party without restriction of disclosure; • They are subject to legal disclosure by any competent court, authority or administration. This confidentiality provision shall survive the termination of the Agreement for any reason until (i) the Confidential Information passes into the public domain other than through a breach by the receiving Party or (ii) for an additional five (5) years unless otherwise expressly provided by law or regulation, depending on which hypothesis occurred first. ## ARTICLE 14. GENERAL PROVISIONS The Agreement is written in English. In the event where it is translated into a foreign language, only the English version shall be deemed authentic in the event of a conflict of interpretation between the different versions. No indication or document may create obligations not included in the Agreement unless they have been the subject of a new agreement between the Parties. This Agreement does not in any case confer on the Partner the status of a FORMANCE employee, representative or agent. The Parties further declare that under no circumstances should this Agreement be considered as constituting any legal person or legal entity whatsoever, and that any form of "affectio societatis" is formally excluded from their relationship. The fact that one of the Parties does not take advantage of a breach by the other Party of any of the obligations referred to in the Agreement shall not be interpreted for the future as a waiver of the obligation in question. In the event where any provision of this Agreement is held to be invalid or unenforceable under any applicable law or regulation and/or any court decision having the force of res judicata, such provision shall be deemed to be unwritten but shall not affect the validity of the other provisions, which shall remain fully applicable. Any notification between the Parties shall be made to their address appearing in the Preamble of the Agreement. In the event of a change of address, the Party concerned shall inform the other Party as soon as possible. By express agreement, the signing of the Agreement entails acceptance as proof of the electronic communications exchanged between the Parties. The printout of these electronic communications shall be considered as an original writing that is authentic between the Parties. In the event of any difficulty of interpretation between any of the headings appearing at the head of the clauses of the Agreement and any of the clauses, the headings shall be declared non-existent. ## ARTICLE 15. JURISDICTION AND APPLICABLE LAW This Agreement, its execution and interpretation as well as the relations between the Parties are exclusively subject to French law.  The Parties shall endeavor to settle amicably any dispute arising between them concerning the interpretation, performance or termination of this Agreement. IN THE ABSENCE OF AN AMICABLE AGREEMENT WITHIN ONE (1) MONTH FROM THE DATE OF REFERRAL BY ONE OF THE PARTIES, THE DISPUTE MAY BE SUBMITTED TO THE COURTS WITHIN THE JURISDICTION OF THE COURT OF APPEAL OF PARIS, TO WHICH JURISDICTION IS EXPRESSLY ASSIGNED, NOTWITHSTANDING PLURALITY OF DEFENDANTS OR THIRD PARTY CLAIMS, INCLUDING FOR EMERGENCY OR PROTECTIVE PROCEDURES, IN REFEREE OR BY PETITION. --- *Lite summary of [Terms of Service](/terms-of-service). Request with `Accept: text/markdown` for this view.* --- title: About Formance description: "Formance builds open-source, programmable financial infrastructure a double-entry ledger and the modules to move, track and reconcile money at scale." canonical: "https://www.formance.com/about" slug: about type: page-lite updated: "2026-07-17T14:08:44.370Z" --- *About* # Open infrastructure for the financial internet # Open infrastructure for the financial internet Formance is building open, programmable financial infrastructure. We help companies design, run, and scale their financial systems with full control and flexibility. Formance builds open-source, programmable financial infrastructure a double-entry ledger and the modules to move, track and reconcile money at scale. ## Page sections ## Section 1: mission *OUR MISSION* ### Money should be a primitive engineers build with, not a black box they integrate around. --- ## Section 2: aboutMap *OUR OFFICES* ### Three offices across Europe and North America. London, Paris, and New York anchor our engineering, product, and go-to-market teams. The map marks where we work—not a remote headcount chart. Each hub ships the same platform: programmable ledgers, payment flows, and reconciliation for production finance. --- ## Section 3: founderTeam *LEADERSHIP* ### Founding team --- ## Section 4: cta ### Track Every Cent. Trust Every Flow. --- *Lite summary of [About Formance](/about). Request with `Accept: text/markdown` for this view.* --- title: "Formance, Money movement infrastructure" description: "One programmable ledger for payments, treasury and reconciliation: model any money movement in Numscript, connect every rail, and close your books continuously." canonical: "https://www.formance.com/" slug: home type: page-lite updated: "2026-07-28T16:00:22.832Z" --- # The ledger your money deserves The open-source programmable ledger for fiat and digital assets. Model any flow of funds, track every cent in real time, and build on the immutable system of record trusted by regulators and auditors. - [Start building](https://portal.formance.cloud?ref=website) - [Book a demo](/demo) One programmable ledger for payments, treasury and reconciliation: model any money movement in Numscript, connect every rail, and close your books continuously. ## Page sections ## Section 1: logoStrip _TRUSTED BY TEAMS MOVING MONEY/ --- ## Section 2: whyFormance *_WHY FORMANCE/* ### The ledger you build on. The record you trust. --- ## Section 3: productLedger *_LEDGER/* ### Always balanced #### A double-entry ledger built for engineers. Model any money movement with Numscript. Every transaction is atomic, immutable, and reconciled by construction, so your books never drift, even at scale. --- ## Section 4: productFlows *_FLOWS/* ### Money, orchestrated #### Payment workflows, declared as code. Compose multi-step flows (splits, fees, holds, payouts) as durable, event-driven programs. Run them reliably across providers with retries and full auditability. --- ## Section 5: productConnectivity *_CONNECTIVITY/* ### Every rail, one model #### One unified model across PSPs and banks. Connect Stripe, Adyen, Wise and dozens of banks behind a single API. Normalize payments, balances, and payouts into one consistent data model your team can rely on. --- ## Section 6: productReconciliation *_RECONCILIATION/* ### Catch drift instantly #### Ledger vs Payments pool, side by side. Compare your Ledger balances against your Payments pooling balances continuously. The moment a day drifts, the gap is surfaced, not discovered weeks later at close. --- ## Section 7: schemaBuilder *_SCHEMA BUILDER/* ### Author ledger schemas in YAML. #### Your chart of accounts, modeled as code. Write the chart of accounts and named transactions, validate as you type, then export to JSON or copy the API commands to bootstrap your ledger. --- ## Section 8: testimonials *_VOICES/* ### Trusted by builders --- ## Section 9: trustWall *_TRUST/* ### Built for regulated money. Enterprise controls, the certifications auditors ask for, and an immutable record, out of the box. --- ## Section 10: useCases *_USE CASES/* ### One ledger. Every use case. From digital assets to corporate treasury, teams build their money movement on one programmable ledger. --- ## Section 11: ctaPanel *_GET STARTED/* ### One platform for every money movement Ledger, connectivity, flows and reconciliation, one programmable foundation your engineers can build on from day one. --- *Lite summary of [Formance, Money movement infrastructure](/). Request with `Accept: text/markdown` for this view.* --- title: "Book a Formance Demo | Platform Consultation" description: Schedule a 30-minute consultation with the Formance team. No generic demo — we start with your architecture and money-movement use case. canonical: "https://www.formance.com/demo" slug: demo type: page-lite updated: "2026-07-13T19:27:17.160Z" --- *DEMO* # Book a consultation No slides, no generic demo. Schedule a 30-minute conversation to understand what you're building and whether Formance is the right fit. Schedule a 30-minute consultation with the Formance team. No generic demo — we start with your architecture and money-movement use case. --- *Lite summary of [Book a Formance Demo | Platform Consultation](/demo). Request with `Accept: text/markdown` for this view.* --- title: Pricing description: "One annual subscription covers the full platform, deployment support, and expert advisory. One package, matched to your scale." canonical: "https://www.formance.com/pricing" type: static-page-lite --- *PRICING* # Built to fit. Priced to scale. One annual subscription covers the full platform, deployment support, and expert advisory. One package, matched to your scale. ## Choose Your Plan ### Open Source (MIT License) A production-grade, double-entry core ledger under MIT License. Full source code access, no restrictions. - Double-entry core ledger - Numscript transaction DSL - Multi-currency, multi-asset tracking - Generic Connector for any provider - CLI & SDKs - Full source code access - Deploy anywhere, your infrastructure ### Enterprise (annual subscription) The full platform with a team behind it. Advanced modules, managed deployment, together with the guidance and support of an expert team so your ledger reaches production faster, stays reliable at scale, and meets the strictest regulatory requirements. - Pre-built PSP, bank & digital asset connectors - Wallets, Flows & Reconciliation modules - Enterprise Authentication, Auditing, Observability, and Streaming - Web Console & Admin Portal - Private Cloud or Assisted Self-Hosted deployment - Designated Solutions Engineer - 24/7 support with 30-min SEV-1 response ## Deployment options ### Private Cloud Formance provisions and manages a dedicated, single-tenant environment in the region(s) of your choice. - Formance handles provisioning, maintenance, upgrades & SRE - 99.9% uptime SLA, 3 AZs, 6-node replication - VPC peering, no data traverses the public internet - Built-in disaster recovery, automated backups & multi-AZ failover - Go live in weeks, no K8s expertise required ### Assisted Self-Hosted Your infrastructure, your control. Formance provides the deployment toolkit, guided provisioning, and ongoing support. - Deploy on your own K8s cluster (AWS, GCP, Azure) - Full data sovereignty and infrastructure control - Guided provisioning & migration support - Same 24/7 support and success package --- title: Newsletter description: "Monthly engineering notes, product updates, and deep-dives on money movement architecture from the Formance team." canonical: "https://www.formance.com/newsletter" type: static-page-lite --- *NEWSLETTER* # Subscribe to the Formance Newsletter Real notes from building financial infrastructure at scale. ## What to expect Perspectives on ledger design, money movement architecture, and the hard parts of financial infrastructure. - Architecture patterns for ledgers, wallets, and payment flows - Deep-dives on double-entry accounting and ledger design - Production postmortems and lessons learned at scale - Product updates and new platform capabilities One email a month. No marketing fluff, and you can unsubscribe any time. --- # Platform --- title: "Ledger for Licensed Institutions | Formance" description: "EMIs, payment institutions, money transmitters and trust charters run Formance as their system of record. Several were licensed on the data stored in it." canonical: "https://www.formance.com/platform/regulatory" slug: regulatory type: platform-page-lite updated: "2026-07-28T15:58:13.774Z" --- *REGULATORY* # The ledger regulated companies take to their regulator EMIs, payment institutions, money transmitters, and trust charters run Formance as their system of record. Several were licensed on the basis of data stored in it. Formance is a technical enabler for regulated entities, not a regulated entity and not a compliance service. The positioning is deliberate: manage your financial data correctly so you can prove compliance to your regulator. Over 60% of Formance customers operate under a financial license, and customers go to their regulator with the Formance Ledger as the core system behind their regulatory processes. ## Frameworks our customers operate under ## Frameworks our customers operate under - **EMI (EU / UK)** — Customers licensed with MFSA, AMF, ACPR, and FCA, with safeguarding and daily reconciliation running on the ledger. - **PI / PSD2** — Payment institutions using the ledger as the transaction system of record. - **MTL (US)** — State money transmitter licensees, with fund tracking and reporting-ready data. - **Trust charters & more** — Banking charters (OSC, FINTRAC), NYDFS-regulated stablecoin issuance, GENIUS and MiCA-aligned reporting. ## What the ledger gives a license application ## What the ledger gives a license application - **Fund segregation** — Segregated account trees, omnibus sub-accounting, and per-customer attribution: the core EMI and MTL safeguarding requirements. - **Daily reconciliation** — Automated matching against banks, PSPs, and custodians, with drift alerts. Proof that no money is unaccounted for. - **Point-in-time proof** — Balance state reconstructed at any historical date, for reference-date reporting and proof-of-reserves attestations. - **Audit trail** — Immutable, hash-chained history with metadata-rich transactions, sliceable by currency, country, scheme, and product for recurring reports. - **Architecture documentation** — System-of-record architecture docs, data model documentation, and security attestations, shaped for regulator submission packs. - **Open-source transparency** — Regulators and auditors can examine the core ledger logic directly. No black box. ## FAQ **DOES FORMANCE HOLD OR TOUCH CUSTOMER FUNDS?** No. Formance is a technology platform. Funds stay with your banks, PSPs, and custodians; the ledger is the system of record that tracks and proves them. **CAN OUR REGULATOR EXAMINE THE SYSTEM?** Yes. The core ledger is open source and auditable, the transaction history is immutable, and reports extract directly from the ledger API in the formats your reporting cadence needs. **HOW DOES SAFEGUARDING REPORTING WORK?** Customer funds map to segregated account trees reconciled daily against safeguarding accounts, and reports reproduce for any date from the immutable log. **DOES FORMANCE DO KYC OR AML SCREENING?** No, by design. Identity and screening stay in your dedicated tooling; the ledger integrates with those systems through events and exports and remains the clean record layer underneath. ## Closing *GET STARTED* ## Bring your license plan Walk through what your regulator will ask for: book a demo or talk to an engineer. --- *Lite summary of [Regulatory](https://www.formance.com/platform/regulatory). Request with `Accept: text/markdown` for this view.* --- title: "SOC 2, ISO 27001 & DORA Compliance | Formance" description: "SOC 2 Type II with zero exceptions, ISO 27001:2022 certification and DORA alignment, backed by evidence you can hand straight to your auditors." canonical: "https://www.formance.com/platform/compliance" slug: compliance type: platform-page-lite updated: "2026-07-28T15:58:16.290Z" --- *COMPLIANCE* # Audited, certified, and continuously monitored SOC 2 Type II with zero exceptions, ISO 27001:2022, and DORA alignment: the certifications your auditors ask for, backed by evidence you can hand them. Compliance at Formance is a program, not a page: independent audits on a fixed cadence, 16 formal security policies reviewed annually, continuous control monitoring in Vanta, and contracts already aligned with EU operational-resilience requirements. Everything below is documented and available under NDA through the trust center. ## SOC 2 Type II ## SOC 2 Type II - **Clean opinion** — Audited by Johanson Group LLP; all 33 Common Criteria tested with no exceptions noted. - **Full scope** — Control environment, risk assessment, access, operations, change management, and vendor risk (CC1 through CC9). - **Annual cadence** — Re-audited on a rolling annual period, with the current report available under NDA. ## ISO 27001:2022 ## ISO 27001:2022 - **Certified ISMS** — Information security management system certified against the 2022 revision. - **Policy suite** — 16 formal policies (access, cryptography, incident response, BC/DR, secure development, and more) reviewed and renewed annually. - **Annual audits** — External audit plus annual risk assessments based on ISO 27005 and NIST 800-30. ## DORA ## DORA - **Assessed, no material deficiencies** — Full assessment across Articles 5 to 30 and Article 45, covering governance, resilience testing, incident reporting, and third-party risk. - **Financial-entity ready** — Contracts aligned with DORA requirements out of the box, and a maintained register of ICT arrangements. - **Resilience testing** — Critical systems tested at least yearly; threat-led penetration testing at least every 3 years by external testers. ## FAQ **HOW DO WE GET THE REPORTS?** Through the trust center under NDA, or alongside your RFP. The latest audit reports ship with security questionnaire responses as standard. **WE ARE IN SCOPE FOR DORA. WHAT DOES THAT MEAN FOR YOU AS OUR ICT PROVIDER?** Formance maintains DORA-aligned contract terms, a register of ICT arrangements, incident classification aligned with Articles 13 and 14, and a resilience testing program, so your third-party risk file is ready. **WHAT ABOUT GDPR?** Formance processes data under a DPA with GDPR-aligned safeguards, EU hosting options, jurisdiction-bound backups, and a published sub-processor list. **DO YOU SUPPORT CUSTOMER AUDITS?** Yes, audit rights are part of the contractual framework, and continuous monitoring evidence (Vanta) plus annual external audits back the paper. ## Closing *GET STARTED* ## Evidence, not assurances Request the reports or bring your compliance team to a session. --- *Lite summary of [Compliance](https://www.formance.com/platform/compliance). Request with `Accept: text/markdown` for this view.* --- title: "Security for Regulated Money | Formance" description: "Single-tenant isolation, encryption everywhere, continuous monitoring and a 24/7 incident response under SLA, with annual external penetration testing." canonical: "https://www.formance.com/platform/security" slug: security type: platform-page-lite updated: "2026-07-28T15:58:18.571Z" --- *SECURITY* # Built and operated for regulated money Single-tenant isolation, encryption everywhere, continuous monitoring, and a 24/7 incident response you can hold to an SLA. Formance runs financial systems of record for regulated companies, and the security program is built to survive their reviews: independent audits with clean opinions, annual external penetration testing, cloud-native detection, and a documented, tested incident response. Reports and attestations live at trust.formance.com; a responsible disclosure policy is published at formance.com/security. ## Architecture ## Architecture - **Single-tenant isolation** — Each cloud customer runs in a dedicated private region in a separate AWS account. Nothing multi-tenant, nothing shared. - **Private networking** — VPC peering to your infrastructure; standard deployments expose nothing to the public internet. - **Encryption** — AES-256 at rest, TLS 1.2+ in transit with HSTS, keys in AWS KMS with rotation and logged access, per NIST SP 800-57. ## Access ## Access - **SSO, MFA, RBAC** — OIDC SSO, MFA on all privileged access, zero-privilege-by-default roles, quarterly access reviews, revocation within 24 business hours of departure. - **Non-repudiation** — Immutable, hash-chained audit logs on every platform and service action, with actor and timestamp. ## Detection & response ## Detection & response - **Continuous monitoring** — AWS GuardDuty, Security Hub, Inspector, and CloudTrail across all production accounts; compliance monitored continuously in Vanta. - **Incident response** — 24/7 on-call with executive escalation, 30-minute Severity-1 first response, plan tested annually, post-mortems after every security incident. - **Testing** — Annual external penetration testing (never internal), additional tests after major changes, quarterly external vulnerability scans. ## Resilience ## Resilience - **Availability** — 99.9% SLA on Formance-hosted deployments across 3 availability zones with 6-node replication. - **Backups** — Encrypted backups, restoration tested at least annually, ledger export for independent copies at any time. - **Track record** — No major security breaches or data loss to date; SOC 2 Type II audit passed with zero exceptions across all 33 criteria. ## Showcase - **SOC 2 Type II** — Audited by Johanson Group LLP; clean opinion, no exceptions noted across all 33 criteria tested. - **ISO 27001:2022** — Certified ISMS; 16 formal security policies reviewed annually. - **DORA** — Assessed across Articles 5 to 30 and 45; no material deficiencies identified. ## FAQ **WHO PERFORMS YOUR PENETRATION TESTS?** Independent external testers, annually and after major changes, with results feeding a documented remediation workflow. Formance also retains an external virtual CISO. **CAN WE FEED YOUR LOGS INTO OUR SIEM?** Yes. Audit logs auto-sync to customer SIEMs, and platform logs and traces export to any OpenTelemetry-compatible backend. **WHERE IS DATA STORED?** In the region you choose, in a dedicated AWS account (cloud) or on your own infrastructure (self-hosted). Backups replicate only within the same jurisdiction. **HOW DO WE RUN OUR SECURITY REVIEW?** Start at trust.formance.com for reports and the sub-processor list, and use InfoSec office hours with the Formance security team for anything deeper. ## Closing *GET STARTED* ## Bring your security review Get the reports, then get your questions answered live: book a demo or visit the trust center. --- *Lite summary of [Security](https://www.formance.com/platform/security). Request with `Accept: text/markdown` for this view.* --- title: "AI & MCP for a Deterministic Ledger | Formance" description: "Design a ledger schema from a plain-language description, then give agents a governed MCP gateway: balance constraints, idempotency and an audit trail." canonical: "https://www.formance.com/platform/ai" slug: ai type: platform-page-lite updated: "2026-07-28T15:58:21.020Z" --- *AI & MCP* # AI designs. The ledger decides. Use AI to design your ledger in minutes, and give agents a governed gateway to act on it: deterministic guarantees underneath, whatever the model does above. AI meets the ledger in two places. At design time, Studio turns a description of your business into a complete ledger schema. At run time, agents act against the ledger through the same enforcement as any other client: balance constraints, idempotency, and an immutable audit trail. Probabilistic systems above, deterministic truth below. ## Design time ## Design time - **Studio** — Describe your flows, attach your documents, and get a complete schema: chart of accounts, Numscript templates, and queries. Free at studio.formance.com. - **Schemas** — The output is a versioned schema object you review, edit, and deploy to your stack in one step. AI proposes; you approve; the ledger enforces. ## Run time ## Run time - **MCP gateway** — Agents connect to the ledger through MCP, so every agent action passes the same authentication, RBAC, and constraints as any API client. - **Ledger-enforced guardrails** — Agent budgets as funded accounts, spend limits as balance constraints, holds for mandate reservations. Enforced at posting time, not in the prompt. - **Exactly-once execution** — Deterministic idempotency keys collapse retried and duplicated tool calls into one transaction. - **Attributed audit trail** — Every agent posting carries actor, task, and authorizing context in an immutable, hash-chained log. ``` // An agent's spend is bounded by its account, // not by its prompt vars { account $agent account $vendor monetary $amount } send $amount ( source = @agents:$agent:budget destination = $vendor ) // Insufficient budget: the transaction fails // atomically. Nothing to clean up. ``` ## FAQ **DOES AI TOUCH MY TRANSACTION DATA?** Studio works at design time on the descriptions and documents you give it. Transaction execution is fully deterministic: no model sits in the posting path. **WHAT EXACTLY DOES STUDIO PRODUCE?** A complete, versioned ledger schema: the chart of accounts, parameterized Numscript templates per business event, and the queries you will run. You review and deploy it as one object. **HOW DO AGENTS CONNECT?** Through the MCP gateway, with the same authentication and RBAC as any client. An agent is a principal with scoped permissions and a funded account, never a superuser. **CAN AGENTS OVERSPEND OR DOUBLE-PAY?** Not structurally. Spend limits are ledger balance constraints checked at posting time, and idempotency keys make retries collapse into a single transaction. ## Closing *GET STARTED* ## Give AI a ledger it cannot break Design your schema in Studio, or talk to us about agentic flows. --- *Lite summary of [AI & MCP](https://www.formance.com/platform/ai). Request with `Accept: text/markdown` for this view.* --- title: "Enterprise Stack for Production | Formance" description: "Six operational modules to run, observe, secure and integrate the platform — access control, auditing, observability, streaming — plus 24/7 support." canonical: "https://www.formance.com/platform/enterprise" slug: enterprise type: platform-page-lite updated: "2026-07-28T15:58:23.642Z" --- *ENTERPRISE STACK* # Everything your team needs to run it in production Six operational modules to run, observe, secure, and integrate the platform, plus the 24/7 service package behind them. A compliant ledger is more than correct postings. It is who may read and write, what trace every action leaves, how the system is observed, how data reaches the rest of your stack, and who answers at 3am. The enterprise stack packages those operational requirements so your team builds product, not platform tooling. ## 01 · Unified interfaces — Local dev to production, one workflow. ## 01 · Unified interfaces — Local dev to production, one workflow. - **fctl CLI & SDKs** — The Formance CLI for day-to-day operations and automation; SDKs in TypeScript, Python, Go, and .NET. - **Admin Portal** — Environment and deployment management. - **Web Console** — Account, transaction, connectivity, and reconciliation monitoring for operations teams. ## 02 · Observability — Full-stack visibility, immutable traceability. ## 02 · Observability — Full-stack visibility, immutable traceability. - **Prometheus & OpenTelemetry** — Metrics and distributed traces, exportable to any OTel-compatible backend. - **Grafana dashboards** — Real-time dashboards, including customer-dedicated ones. - **Structured audit logs** — Every platform and service action in an immutable, hash-chained trace with actor and timestamp. ## 03 · Identity & access — Secure access, enterprise-grade controls. ## 03 · Identity & access — Secure access, enterprise-grade controls. - **Auth module** — OAuth 2.0 / OIDC / JWT for humans and machine tokens. - **SSO (OIDC)** — Plug into your identity provider; MFA enforced through your IdP policies. - **Fine-grained RBAC** — Precise read, write, and resource scopes. Zero privilege by default. ## 04 · Extensibility — Real-time integrations, custom workflows. ## 04 · Extensibility — Real-time integrations, custom workflows. - **Events streaming (Kafka, NATS)** — Continuous, real-time event streams for every platform service. - **Webhooks** — Ad-hoc, real-time notifications for custom integrations. - **API gateway** — One governed entry point for every module's API. ## 05 · Ledger exporters — Ledger data where your analysts already work. ## 05 · Ledger exporters — Ledger data where your analysts already work. - **Streaming pipeline** — Continuous export of ledger data to your warehouse. - **Snowflake, BigQuery, Redshift, object storage** — Native destinations for analytics and archival. - **Continuous, replayable export** — Deterministic, resumable pipelines: re-derive downstream state from the log at any time. ## 06 · Deployment toolkit — Repeatable deploys, safe upgrade cycles. ## 06 · Deployment toolkit — Repeatable deploys, safe upgrade cycles. - **Kubernetes Operator** — Productized multi-tenant deployment and lifecycle management. - **Kubernetes Agent** — The control-plane client for self-hosted and CloudPrem deployments. - **Helm charts** — Official charts for repeatable installs on AWS, Azure, or GCP. ## The service behind the modules ## The service behind the modules - **24/7 support** — 30-minute Severity-1 first response, multi-layer escalation up to executives. - **Onboarding & success** — Solution design workshops, chart-of-accounts design, migration guidance, monthly check-ins. - **Compliance support** — SOC 2 and ISO reports, DPA, sub-processor transparency, InfoSec office hours for security reviews. ## FAQ **WHAT IS OPEN SOURCE AND WHAT IS ENTERPRISE?** Ledger, Numscript, and connectors are MIT-licensed open source. Flows, Reconciliation, and the operational modules above (interfaces, observability, identity, extensibility, exporters, deployment toolkit) are enterprise, with escrow provisions in the MSA. **HOW DOES LEDGER DATA REACH OUR WAREHOUSE AND SIEM?** Exporters stream ledger data continuously to Snowflake, BigQuery, Redshift, or object storage with replayable pipelines; audit logs auto-sync to your SIEM; metrics and traces export to any OpenTelemetry-compatible backend. **HOW GRANULAR IS RBAC?** Roles attach to human users or machine tokens with precise read, write, and resource scopes. Entities are created with zero privilege and must be granted roles explicitly. **WHAT DOES SUPPORT ACTUALLY COMMIT TO?** 99.9% availability SLA on Formance-hosted deployments, 30-minute first response on Severity 1 with updates every 2 hours, 24/7 on-call with escalation to executives, and service credits for SLA misses. ## Closing *GET STARTED* ## Production-grade from day one See the operational modules in detail: book a demo or start building. --- *Lite summary of [Enterprise Stack](https://www.formance.com/platform/enterprise). Request with `Accept: text/markdown` for this view.* --- title: "Self-Hosted or Private Cloud | Formance" description: "Run Formance self-hosted on your own Kubernetes for full data sovereignty, or in a dedicated single-tenant private cloud managed by Formance." canonical: "https://www.formance.com/platform/deployment" slug: deployment type: platform-page-lite updated: "2026-07-28T15:58:26.086Z" --- *DEPLOYMENT OPTIONS* # Your infrastructure or ours. Same platform. Run Formance self-hosted on your own Kubernetes for full data sovereignty, or in a dedicated single-tenant private cloud managed by Formance. Start open source: Ledger and Connectivity are MIT-licensed and freely deployable anywhere. Enterprise adds the proprietary modules, the operational stack, and the support package, in whichever deployment model fits your regulatory posture. About 60% of Formance customers self-host; the rest run a dedicated private cloud. Either way, non-production environments can be created at will at no additional cost. ## The three ways to run Formance ## The three ways to run Formance - **Open source** — Ledger and Connectivity under MIT. Deploy anywhere, inspect everything, no usage restrictions. The evaluation and early-stage path. - **Enterprise Self-Hosted** — Deploy on your own Kubernetes (AWS, Azure, GCP) via official Helm charts, Operator, and Agent. Your infrastructure, your data, your region. The choice of most regulated customers. - **Enterprise Private Cloud** — Fully managed single-tenant environment in a dedicated AWS account, in the region you choose (for example EU Ireland or US N. Virginia). 3 availability zones, 6-node replication, 99.9% uptime SLA. ## What Enterprise adds in any model ## What Enterprise adds in any model - **Modules** — Flows, Reconciliation, and the proprietary connector set on top of the open-source core. - **Operations** — SSO, RBAC, audit logs, observability, real-time events, Console and Admin portal. - **Support** — 24/7 incident response, 30-minute Severity-1 first response, multi-layer escalation, onboarding and success plan. ## FAQ **CAN WE START MANAGED AND MOVE TO SELF-HOSTED?** Yes. A Formance-hosted environment runs in a dedicated AWS account that can be transferred to you for self-hosting later, so the migration path is an account handover, not a rebuild. **WHO OPERATES WHAT IN SELF-HOSTED?** You run the infrastructure; Formance provides the Operator, Helm charts, upgrade tooling, and support that covers provisioning, management, and monitoring. Hybrid observability is possible. **WHERE DOES OUR DATA LIVE?** Self-hosted: on your infrastructure, wherever you run it. Private Cloud: in a dedicated AWS account in your chosen region, with backups replicated only within the same jurisdiction. **WHAT ABOUT ENVIRONMENTS?** Create non-production environments (dev, staging, sandbox) at will at no extra cost. Production deployment count is part of the contract. ## Closing *GET STARTED* ## Deploy on your terms Talk through the model that fits your posture: book a demo or start building. --- *Lite summary of [Deployment Options](https://www.formance.com/platform/deployment). Request with `Accept: text/markdown` for this view.* --- title: "Connector Directory: Banks, PSPs, Crypto | Formance" description: "Every pre-built connector across banks, PSPs, open banking and digital-asset rails. Filter by category and capability, or build your own in 2 to 4 weeks." canonical: "https://www.formance.com/platform/connectors" slug: connectors type: platform-page-lite updated: "2026-07-28T15:58:28.348Z" --- *CONNECTORS* # The connector directory Every pre-built connector across banks, PSPs, open banking, and digital-asset rails. Filter by category and capability, or build your own on the Generic Connector framework. ## FAQ **WHAT IF MY PROVIDER IS NOT LISTED?** Use the Generic Connector framework (typically 2 to 4 weeks to implement), co-develop with Formance, or request it. New connectors are added continuously and all are open source. **CAN I REALLY SWAP PROVIDERS?** Yes. Your integration targets the uniform model, not the provider's API. Moving from one PSP to another is a connector configuration change; your flows and reconciliation logic stay intact. **DO CONNECTORS EXECUTE PAYMENTS?** Yes. Connectivity is bidirectional: it ingests transaction data and executes transfers and payouts, and a payment can be the entry point or a step of a Flow. **HOW DOES THIS FEED RECONCILIATION?** Connector data lands already normalized and linked, so reconciliation policies match external statements against ledger state continuously, with drift alerts instead of month-end surprises. ## Closing *GET STARTED* ## Integrate once, swap freely See the catalog against your stack: start building or book a demo. --- *Lite summary of [Connectors](https://www.formance.com/platform/connectors). Request with `Accept: text/markdown` for this view.* --- title: "Numscript: a Language for Money | Formance" description: "An open-source language for financial transactions: declare what should move and the ledger executes it atomically, balanced, with deterministic math." canonical: "https://www.formance.com/platform/numscript" slug: numscript type: platform-page-lite updated: "2026-07-28T15:58:30.279Z" --- *NUMSCRIPT* # Describe the money. The ledger does the rest. An open-source language for financial transactions: declare what should move, and the ledger executes it atomically, balanced, with deterministic integer math. No orchestration, no cleanup, no mystery money. A simple "move funds from A to B" becomes a system of chained API calls, balance checks, and conditional logic, and every addition introduces risk. Balances fall out of sync, logs fill with partial data, and nobody can reconstruct what really happened. Numscript replaces that orchestration with a declaration: you describe what the transaction means, the ledger guarantees how it executes. The shift is from procedural code that manages money to a language that describes it. Engineers get fewer failure modes, finance gets logic they can read, auditors get a single source of truth. ## The guarantees ## The guarantees - **Atomic execution** — All postings commit, or none do. A partial execution is not a state the ledger can be in. - **Balanced by construction** — A Numscript program cannot produce an unbalanced posting. Double-entry is the physics, not a convention. - **Deterministic integer math** — Integer-only amounts in Unambiguous Monetary Notation ([USD/2 599] is $5.99). No floating point, ever, so the same inputs always produce the same postings. - **Predictable rounding** — Indivisible remainders allocate from the top of the destination list down, by rule. No invisible fractions, no mystery money. - **No accidental overdraft** — Accounts cannot go negative unless the script says so, explicitly and boundedly (overdraft up to an amount, or allowing unbounded where intended). - **No race conditions** — The ledger handles locking and sequencing. Concurrency safety is not your application's problem. ## The vocabulary ## The vocabulary - **send** — One statement per movement: an amount, a source, a destination. - **Ordered sources** — Pull from several accounts in priority order (spend the coupon first, then the user's balance). - **Split destinations** — Percentages, nested splits, and remaining for whatever is left. - **max caps** — Bound any leg: take at most $20 from the promotion account, the rest from the user. - **Variables and metadata** — Parameterize accounts, amounts, and portions per execution; read rates and tiers from account metadata; write context onto the transaction. - **Templates** — One reviewed, versioned script per business event: settle, refund, payout, write-off. ## The toolchain (open source, MIT) ## The toolchain (open source, MIT) - **Standalone interpreter** — Implemented in portable Go with a formal ANTLR grammar. Not locked inside the Formance stack. - **CLI** — Parse, check, and run scripts locally; install via curl or go install. - **Language server** — Diagnostics, hover, symbols, and go-to-definition in your editor. - **Playground** — Try flows in the browser at playground.numscript.org, no setup. ## Showcase ## Both are single atomic transactions. If any leg cannot post, nothing posts. A marketplace payout: nested splits, deterministic remainder. ``` send [USD/2 599] ( source = @rides:0234 destination = { 85% to @drivers:042 remaining to { 10% to @charity remaining to @platform:fees } } ) ``` ``` send [USD/2 29900] ( source = { 10% from { max [USD/2 2000] from @coupons:FALL24 @users:1234 } remaining from @users:1234 } destination = @payments:4567 ) ``` ## FAQ **IS NUMSCRIPT A FULL PROGRAMMING LANGUAGE?** No, deliberately. No loops, no side effects, no I/O. It describes money movement and nothing else, which is what makes it verifiable, auditable, and safe to run against real balances. **HOW DOES IT AVOID ROUNDING ERRORS?** Amounts are integers in Unambiguous Monetary Notation, so precision is explicit per asset ([USD/2], [BTC/8]). Splits that leave an indivisible unit allocate it deterministically from the top of the list down. The same script and inputs always produce identical postings. **IS IT TIED TO THE FORMANCE LEDGER?** Numscript is the transaction language of the Formance Ledger, but the interpreter is a standalone open-source project (Go, MIT, formal grammar), with its own CLI, language server, and playground. **WHO WRITES IT, AND HOW IS IT TESTED?** Engineers write and version one template per business event; product, finance, and auditors can read them. Iterate in the playground, validate with the CLI and language server, run against a sandbox ledger. Determinism means what passes in test behaves identically in production. ## Closing *GET STARTED* ## Write the flow, not the plumbing Try a real flow in the playground, or start building against a sandbox. --- *Lite summary of [Numscript](https://www.formance.com/platform/numscript). Request with `Accept: text/markdown` for this view.* --- title: "Ledger Design Primitives | Formance" description: "The guarantees the system of record is built on: books that cannot drift, cannot rewrite the past, and cannot be spent into states that never happened." canonical: "https://www.formance.com/platform/primitives" slug: primitives type: platform-page-lite updated: "2026-07-28T15:58:32.897Z" --- *LEDGER DESIGN PRIMITIVES* # Guarantees, not features The properties the system of record is built on. Every one is a property of the ledger, not application code you maintain. A financial database is only as good as what it makes impossible. These primitives are why books on Formance cannot drift, cannot lie about the past, and cannot be spent into states that never happened. They come from the demo slide used with every technical evaluator, organized in four groups. ## Correctness & integrity · Never wrong ## Correctness & integrity · Never wrong - **Double-entry** — Every posting balances by construction. - **Atomic transactions** — All legs commit, or none do. - **Idempotency** — Safe replays via idempotency keys. - **Concurrency control** — Correct under high parallelism. - **Strongly-consistent balances** — Reads reflect every committed posting. - **Asset coloring** — Preserve each unit's identity in a pool. ## Structure & modeling · Model any book ## Structure & modeling · Model any book - **Hierarchical accounts** — Colon-delimited paths model your whole book. - **Flexible aggregation** — Roll up at any segment in constant time. - **Multi-asset accounts** — Any currency or unit on the same account. - **Volumes** — Cumulative inflow and outflow, per asset. - **Exact-integer amounts** — No floating-point drift, ever. - **Derived balances** — Computed from the log, never stored. ## History & time · Provable past ## History & time · Provable past - **Immutability (hash-chained)** — Tamper-evident append-only log. - **Bi-temporality** — Effective time and record time, both. - **Point-in-time views** — Reconstruct any balance, any date. - **Versioned posting rules** — Effective-dated logic changes. - **Native reversals** — Compensating entries, not deletes. ## Control & governance · In your hands ## Control & governance · In your hands - **Overdraft controls** — Bounded or unbounded, per account. - **Non-repudiation** — Every change attributable to an actor. - **Metadata** — Queryable context on every entity. - **Schema enforcement** — Reject undefined or malformed accounts. - **Multi-tenant isolation** — Isolated books within one deployment. ## Closing *GET STARTED* ## Build on guarantees, not conventions See the primitives in your own flows: start building or book a demo. --- *Lite summary of [Ledger Primitives](https://www.formance.com/platform/primitives). Request with `Accept: text/markdown` for this view.* --- # Solutions --- title: For Operations description: "One live view across every provider, automated matching with drift alerts, and an exception queue instead of an Excel marathon." canonical: "https://www.formance.com/solutions/teams/operations" type: solution-lite updated: "2026-07-28T15:58:35.167Z" --- *FOR OPERATIONS* # Retire the reconciliation spreadsheet One live view across every provider, automated matching with drift alerts, and an exception queue instead of an Excel marathon. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Flow of funds *FLOW OF FUNDS* ## Capabilities *CAPABILITIES* ## Metrics *BY THE NUMBERS* ## Code *NUMSCRIPT* numscript ## FAQ **DO WE HAVE TO CHANGE PROVIDERS?** No. Connectors bring your existing banks, PSPs, and custodians into one model; reconciliation runs across whatever stack you already have. **WHAT HAPPENS WHEN SOMETHING DOES NOT MATCH?** It lands in the exception queue with the internal record, the external statement, and the full transaction trace side by side, so resolution is minutes of context, not hours of archaeology. ## Closing *GET STARTED* ## See your month-end, automated Book a demo with your provider stack. --- *Lite summary of [For Operations](https://www.formance.com/solutions/teams/operations). Request with `Accept: text/markdown` for this view.* --- title: For Finance description: "Continuous reconciliation, immutable history, and point-in-time balances: close faster and walk into every audit with evidence instead of spreadsheets." canonical: "https://www.formance.com/solutions/teams/finance" type: solution-lite updated: "2026-07-28T15:58:37.536Z" --- *FOR FINANCE* # Books that prove themselves Continuous reconciliation, immutable history, and point-in-time balances: close faster and walk into every audit with evidence instead of spreadsheets. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Flow of funds *FLOW OF FUNDS* ## Capabilities *CAPABILITIES* ## Metrics *BY THE NUMBERS* ## Code *NUMSCRIPT* numscript ## FAQ **DOES THIS REPLACE OUR ERP OR GL?** No. Formance is the operational system of record underneath; your ERP keeps consuming roll-ups for statutory accounting. Each system does what it is good at. **WILL OUR AUDITORS ACCEPT IT?** The transaction history is immutable and tamper-evident, reports reproduce for any date, and the platform carries SOC 2 Type II and ISO 27001. Auditors get direct evidence rather than reconstructed exports. ## Closing *GET STARTED* ## See your close, continuous Book a demo with your own flows of funds. --- *Lite summary of [For Finance](https://www.formance.com/solutions/teams/finance). Request with `Accept: text/markdown` for this view.* --- title: For Product description: "Launch wallets, splits, payouts, and new asset types as product decisions, not infrastructure projects." canonical: "https://www.formance.com/solutions/teams/product" type: solution-lite updated: "2026-07-28T15:58:39.797Z" --- *FOR PRODUCT* # Your roadmap, unblocked from the ledger Launch wallets, splits, payouts, and new asset types as product decisions, not infrastructure projects. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Flow of funds *FLOW OF FUNDS* ## Capabilities *CAPABILITIES* ## Metrics *BY THE NUMBERS* ## Code *NUMSCRIPT* numscript ## FAQ **WILL ENGINEERING ACCEPT IT?** Engineering can evaluate the open-source core on GitHub before committing to anything, which is exactly how most Formance evaluations start. You are proposing a foundation, not a vendor black box. **HOW FAST CAN WE ACTUALLY LAUNCH?** First use cases typically reach production in 4 to 6 weeks; full deployments run 3 to 6 months depending on scope and migration. ## Closing *GET STARTED* ## Bring the feature you cannot ship today Book a demo and see it modeled live. --- *Lite summary of [For Product](https://www.formance.com/solutions/teams/product). Request with `Accept: text/markdown` for this view.* --- title: For Engineering description: "The correctness problems that eat your roadmap (concurrency, idempotency, atomic multi-leg postings, audit trails) are solved, in production, open source." canonical: "https://www.formance.com/solutions/teams/engineering" type: solution-lite updated: "2026-07-28T15:58:42.262Z" --- *FOR ENGINEERING* # Stop maintaining a ledger. Start shipping product. The correctness problems that eat your roadmap (concurrency, idempotency, atomic multi-leg postings, audit trails) are solved, in production, open source. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Flow of funds *FLOW OF FUNDS* ## Capabilities *CAPABILITIES* ## Metrics *BY THE NUMBERS* ## Code *NUMSCRIPT* numscript ## FAQ **WE COULD BUILD THIS OURSELVES.** You could. The question is whether 12 to 24 months of ledger correctness work (concurrency, idempotency, immutability, recovery) beats building your actual product on a foundation that is already audited and in production. Open source means you keep the control that made building attractive. **HOW DO WE EVALUATE IT?** Clone the repo, run the ledger locally, try flows in the Numscript playground, or take a cloud sandbox. The technical evaluation needs nobody's permission. ## Closing *GET STARTED* ## Evaluate it like engineers do Start on the open-source core, or bring your hardest flow to a technical session. --- *Lite summary of [For Engineering](https://www.formance.com/solutions/teams/engineering). Request with `Accept: text/markdown` for this view.* --- title: Token Accounting description: "The effective price of a token spreads ~50x across model, cache state, batch, mode, region, and channel, and the cost of serving moves just as fast. Billing platforms meter what you charge; the question that decides pricing (\"what did we make on this customer, this hour, on this model?\") has no system of record." canonical: "https://www.formance.com/solutions/ai/token-accounting" type: solution-lite updated: "2026-07-28T15:58:44.602Z" --- *TOKEN ACCOUNTING* # Tokens are a currency. Give them a ledger. Post every billable event atomically (customer balance, revenue, and cost of serving together) and know your margin per model, per customer, per dimension, in real time. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Your billing platform meters revenue. It cannot see cost. ### Consumption AI breaks the traditional billing stack. The effective price of a token spreads ~50x across model, cache state, batch, mode, region, and channel, and the cost of serving moves just as fast. Billing platforms meter what you charge; the question that decides pricing ("what did we make on this customer, this hour, on this model?") has no system of record. > Formance runs event-level consumption ledgers in production: hundreds of thousands of monthly events, zero reconciliation errors across 18 months. - Effective token pricing spans model, cache state, batch, mode, region, and channel, and margin per customer is a quarterly estimate, not a number. - Billing tools track what you charge, never what it cost to serve: the dual balance does not exist anywhere. - Cloud marketplace remittances arrive as aggregated wholesale sums that someone reconciles back to per-token usage by hand. - Prepaid commits with real-time drawdown and monthly true-ups are bent into subscription billers that cannot express them. ## Flow of funds *FLOW OF FUNDS* ## Every billable event, fully posted ### One event updates balance, revenue, and cost, atomically. A token event draws down the customer's prepaid balance, recognizes revenue on its exact dimensions, and accrues the cost of serving: one atomic transaction, billions of times, so margin is a query instead of a month-end model. *margin by dimension* - token event: billable call - atomic posting: balance · revenue · cost - margin: per model · per customer - channel settle: direct · marketplace ## Capabilities *CAPABILITIES* ## The primitives consumption AI needs ### Built on the open-source Formance ledger. Event-level posting, dual-balance margin, native commit drawdown, and channel reconciliation, composed for businesses that bill by the token. - **EVENT-LEVEL POSTING** — Every billable event posts atomically across customer, model, and channel accounts: thousands per second sustained, exactly-once, replay-safe. - atomic at token scale - **DUAL-BALANCE MARGIN** — Revenue and cost of serving accounted side by side on the same dimensions: margin per customer, model, or region is a real-time query, not a data project. - cost beside revenue - **COMMITS & DRAWDOWN** — Prepaid commits as wallet balances with real-time drawdown and monthly true-up to the floor: native, not bent into a subscription object. - native drawdown - **CHANNEL RECONCILIATION** — Aggregated marketplace remittances matched back to per-event usage per channel, so wholesale revenue is as auditable as direct. - wholesale to per-event ## Metrics *BY THE NUMBERS* ## Consumption-scale accounting - **9+** — pricing dimensions - **2** — balances per event - **real-time** — margin visibility - **audit-grade** — revenue history ## Code *NUMSCRIPT* ## One event, three postings, zero drift ### Drawdown, revenue, and cost: one atomic transaction. A single Numscript transaction draws down the prepaid commit, recognizes revenue on the event's exact dimensions, and accrues the cost of serving: the three balances can never disagree. ## FAQ **IS THIS A BILLING SYSTEM?** No: it is the substrate underneath one. Keep your payment provider and biller for invoicing and collection; the ledger holds the event-level state of record they all read from. **CAN IT HANDLE BILLIONS OF EVENTS?** The ledger sustains thousands of transactions per second per ledger and scales horizontally. Aggregation across dimensions derives from the log, not from a warehouse recomputation. **HOW DO MARKETPLACE CHANNELS RECONCILE?** Wholesale remittances arrive aggregated; the ledger already holds per-event usage per channel, so matching them is a reconciliation policy, not a quarterly data project. **DOES IT SURVIVE AN AUDIT?** Yes: an append-only, immutable event history with per-dimension revenue states gives finance an ASC 606 basis and auditors direct evidence, at consumption scale. ## Closing *GET STARTED* ## Know your margin while the tokens are still flowing See how Formance fits your consumption stack: book a demo or start building. --- *Lite summary of [Token Accounting](https://www.formance.com/solutions/ai/token-accounting). Request with `Accept: text/markdown` for this view.* --- title: AI Agent Payments description: "A stack of new protocols is racing to let agents pay (mandates, agent cards, agent wallets, agentic checkout), but they all solve authorization, not accounting. A retried tool call can still double-pay, a hallucinated parameter can still overspend, and when the auditor asks why money moved, a chat log is not an answer. With fleets running tens of thousands of tasks, setting limits by hand is not humanly possible." canonical: "https://www.formance.com/solutions/ai/agentic-payments" type: solution-lite updated: "2026-07-28T15:58:47.936Z" --- *AI AGENT PAYMENTS* # Let agents move money without losing control of it Give AI agents a ledger to act on: budgets they cannot exceed, transactions they cannot duplicate, and an immutable record of everything they did and why. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Agents are getting wallets before they get guardrails ### Autonomous money movement without a system of record is a liability engine. A stack of new protocols is racing to let agents pay (mandates, agent cards, agent wallets, agentic checkout), but they all solve authorization, not accounting. A retried tool call can still double-pay, a hallucinated parameter can still overspend, and when the auditor asks why money moved, a chat log is not an answer. With fleets running tens of thousands of tasks, setting limits by hand is not humanly possible. > Formance ships an MCP server, so agents post to the ledger through the same guarantees as any other client, never around them. - Agent spend limits live in prompts, and prompts are not controls. - Retried and replayed tool calls double-pay because nothing enforces idempotency. - Nothing ties a settled transaction back to the agent, the task, and the mandate that authorized it. - Fleet spend fragments across rails (an agent card here, a stablecoin wallet there) with no single record of what the fleet spent. ## Flow of funds *FLOW OF FUNDS* ## Intent, guardrail, posting, proof ### The agent proposes; the ledger constrains, executes, and remembers. The agent's payment intent, carrying its mandate, hits a budgeted account with ledger-enforced limits, posts atomically with a deterministic idempotency key, and lands in an immutable log attributed to the agent, the task, the delegating human, and the credential that authorized it. *agent guardrails* - agent intent: tool call - budget check: ledger-enforced - atomic posting: idempotent - audit trail: who · what · why ## Capabilities *CAPABILITIES* ## The primitives agentic money needs ### Built on the open-source Formance ledger. Ledger-enforced budgets, replay-safe execution, and full attribution, composed for autonomous financial workflows. - **AGENT BUDGETS** — Each agent operates from a funded account inside a budget hierarchy (org → team → user → workflow → agent) with balance constraints the ledger enforces: an agent structurally cannot spend money it does not have. - enforced, not prompted - **REPLAY-SAFE EXECUTION** — Deterministic idempotency keys collapse retried and duplicated tool calls into one transaction: double-pays are impossible by construction. - exactly-once - **FULL ATTRIBUTION** — Every posting carries agent, task, session, delegating principal, and the mandate or credential that authorized it (an AP2-style intent, an agent-card token, an x402 receipt): the "why" behind every cent, queryable forever. - who, what, why - **MCP & APPROVALS** — Agents connect through the Formance MCP server, query their remaining budget and request limit changes programmatically mid-task, and high-value flows route through human approval: human on the loop by policy, in the loop by exception. - human on the loop ## Metrics *BY THE NUMBERS* ## Agent-grade controls - **0** — double-pays - **100%** — action attribution - **enforced** — spend limits - **optional** — human approval ## Code *NUMSCRIPT* ## Authorize the maximum, settle the actual ### The x402 upto pattern, atomic end to end. The agent authorizes a maximum spend, actual consumption settles to the vendor, and the unused balance returns to the agent in the same atomic operation. A partial execution is not a state the ledger can be in, and an agent that cannot cover the authorization fails cleanly, with no overdraft to clean up. ## FAQ **HOW IS THIS DIFFERENT FROM PROMPT-LEVEL LIMITS?** Prompts are suggestions; ledger constraints are physics. An agent's account balance and sending rules are enforced at posting time, no matter what the model decides. **WHAT HAPPENS WHEN AN AGENT RETRIES A PAYMENT?** Every intent carries a deterministic idempotency key, so retries, replays, and duplicated tool calls collapse into one transaction, exactly-once by construction. **CAN A HUMAN APPROVE BEFORE MONEY MOVES?** Yes: flows can route through approval steps above a threshold, where the agent proposes, a human confirms, and the ledger executes and records both. **HOW DO AUDITORS SEE AGENT ACTIVITY?** Every posting is immutable and attributed (agent, task, session, delegating principal, authorizing mandate), so agent spend audits are ledger queries, not log archaeology. The record is rail-agnostic: agent cards today, stablecoin wallets and x402 tomorrow, bank rails throughout. ## Closing *GET STARTED* ## Give your agents a ledger, not a liability See how Formance fits your agentic stack: book a demo or start building. --- *Lite summary of [AI Agent Payments](https://www.formance.com/solutions/ai/agentic-payments). Request with `Accept: text/markdown` for this view.* --- title: "GPU & Compute Marketplaces" description: "Compute is delivered in hours, billed in dollars, and settled in USDC and fiat, across operators, tenants, and financing partners. Usage lives in one system, invoices in another, and the underwriters funding nine-figure GPU deals have no book to underwrite against." canonical: "https://www.formance.com/solutions/ai/compute-marketplaces" type: solution-lite updated: "2026-07-28T15:58:51.081Z" --- *GPU & COMPUTE MARKETPLACES* # Ledger compute like money, because it is Meter GPU-hours as a first-class asset, convert delivered compute into invoices and settlement, and keep operators, tenants, and rails in one auditable record, at inference-provider volume. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## The compute economy runs on IOUs nobody can audit ### Billions in GPU spend, settled on spreadsheets and screenshots. Compute is delivered in hours, billed in dollars, and settled in USDC and fiat, across operators, tenants, and financing partners. Usage lives in one system, invoices in another, and the underwriters funding nine-figure GPU deals have no book to underwrite against. > An AI compute payments platform runs its system of record on the open-source Formance ledger, from metered GPU-hours to settled fiat. - Delivered compute, billed usage, and collected cash live in three unconnected systems, and the mirror database drifts from all of them. - USDC and fiat settlement with unlocked pricing makes every conversion a bespoke booking. - Operator payouts and tenant invoices are computed in batch, disputed by email. - Unit economics shift with every hardware generation and workload mix, and financing partners underwriting GPU deployments have no auditable usage-to-revenue record. ## Flow of funds *FLOW OF FUNDS* ## From GPU-hour to settled dollar ### Delivered, billed, collected, and paid out: one chain, two units. Delivered compute posts as a metered asset, invoicing converts it into a tenant payable and an operator receivable, collection settles in USDC or fiat, and the operator is paid: every step double-entry, both units reconciled. *usage-to-revenue* - compute delivered: GPU-hours metered - billed: usage → invoice - collected: USDC · fiat - operator payout: settled ## Capabilities *CAPABILITIES* ## The primitives the compute economy needs ### Built on the open-source Formance ledger. Asset-agnostic metering, dual-unit accounting, and multi-rail settlement, composed for compute marketplaces. - **COMPUTE AS AN ASSET** — Ledger GPU-hours, tokens, or any usage unit with the same double-entry guarantees as money: delivered, reserved, consumed, and billed states all explicit. - asset-agnostic by design - **USAGE-TO-REVENUE** — Convert metered usage into tenant payables and operator receivables in one atomic exchange: the usage ledger and the money ledger never drift, and unit margin per workload is a query, not a model. - dual-unit atomicity - **MULTI-RAIL SETTLEMENT** — Collect and settle across USDC and fiat rails with per-rail clearing models (gross with fee skim, or net on funding batch), each netting to zero by construction. - per-rail clearing - **UNDERWRITING-GRADE RECORD** — Hand financing partners an auditable usage-to-revenue history per operator and per deployment: the book that GPU lending has been missing. - a book to underwrite ## Metrics *BY THE NUMBERS* ## Compute-economy grade - **any** — metered unit - **2** — units, one record - **USDC + fiat** — settlement rails - **100%** — usage-to-cash trail ## Code *NUMSCRIPT* ## Usage converts to revenue atomically ### GPU-hours out, dollars owed: one transaction. One Numscript transaction bills delivered compute: the consumed GPU-hours move to billed state while the tenant's payable and the operator's receivable open in the same operation. ## FAQ **CAN THE LEDGER REALLY HOLD GPU-HOURS?** Yes: the ledger is asset-agnostic: define GPUH (or tokens, or credits) as an asset and it gets the same atomicity, precision, and auditability as USD. **HOW DO USDC AND FIAT COEXIST?** Both post to the same model. Conversions are explicit transactions with rates and spreads booked, and each rail's clearing account nets to zero by construction. **WHAT ABOUT VOLATILE PRICING?** Rates are captured per conversion at booking time, so the usage-to-revenue history stays exact even when pricing moves between delivery and settlement. **WHY DOES UNDERWRITING CARE?** GPU financings are nine-figure bets on future usage revenue. An immutable usage-to-cash record per operator is the underwriting book that has not existed. ## Closing *GET STARTED* ## The system of record for the compute economy See how Formance fits your marketplace: book a demo or start building. --- *Lite summary of [GPU & Compute Marketplaces](https://www.formance.com/solutions/ai/compute-marketplaces). Request with `Accept: text/markdown` for this view.* --- title: Ledger Modernization description: "The legacy GL runs on rigid account strings, nightly batches, and screens your team works around. Every new workflow (a portal, an automation, real-time reporting) fights the system it depends on, and replacing it feels like open-heart surgery." canonical: "https://www.formance.com/solutions/corporate-treasury/ledger-modernization" type: solution-lite updated: "2026-07-28T15:58:54.230Z" --- *LEDGER MODERNIZATION* # Retire the legacy ledger without betting the close Move off Great Plains-era systems onto a programmable, API-first ledger: shadow-run both, prove they agree, then cut over with history intact. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## The ERP ledger was built for batches, not products ### Rigid GL strings cannot power modern finance operations. The legacy GL runs on rigid account strings, nightly batches, and screens your team works around. Every new workflow (a portal, an automation, real-time reporting) fights the system it depends on, and replacing it feels like open-heart surgery. > Enterprises replace legacy AR ledgers with Formance as the system of record, keeping the ERP for what it is good at. - Rigid GL strings encode the org chart of a decade ago, and every change is a project. - The ledger is batch-based, so balances are yesterday's truth at best. - Building modern tools (portals, automations, dashboards) against the old ERP means screen-scraping and CSV exports. - Migration risk is existential: get it wrong and you cannot close the quarter. ## Flow of funds *FLOW OF FUNDS* ## Shadow first, then cut over ### Both ledgers run until they agree; then the old one retires. Live events stream into Formance while history migrates through a mapped bulk import. The shadow ledger reconciles against the legacy system until both agree on every balance; then you cut over, with the ERP consuming roll-ups downstream. *shadow reconciliation* - legacy GL: system of record today - mapping: CoA translation - shadow ledger: both run, reconciled - cutover: Formance is the record ## Capabilities *CAPABILITIES* ## The primitives modernization needs ### Built on the open-source Formance ledger. A programmable chart of accounts, bulk migration tooling, and an API-first surface, composed for replacing legacy ledgers safely. - **FLEXIBLE CHART OF ACCOUNTS** — Replace rigid GL strings with a dimensional account structure designed around how the business works now, and change it when the business changes. - designed with you - **BULK MIGRATION** — History migrates through bulk endpoints at balance or transaction level, through an explicit mapping from the old chart to the new. - mapped, repeatable - **SHADOW RECONCILIATION** — Run Formance alongside the legacy ledger and reconcile them continuously: cut over only when both agree on everything. - prove before cutover - **API-FIRST SURFACE** — Every balance and posting available over API and events in real time: build the portals and automations the ERP never allowed. - build on top ## Metrics *BY THE NUMBERS* ## Modernization without the cliff - **0** — big-bang cutovers - **100%** — history preserved - **real-time** — balances - **weeks** — to first shadow run ## Code *NUMSCRIPT* ## The new ledger speaks your dimensions ### GL strings become structured accounts you can query. A legacy GL string like 100-B0313-AR becomes a structured, queryable account path: same meaning, real structure, and every roll-up derived instead of report-coded. ## FAQ **DO WE REPLACE THE ERP ENTIRELY?** No: Formance becomes the operational system of record for money movement; the ERP keeps consuming roll-ups for statutory accounting. Each system does what it is good at. **HOW DOES THE MIGRATION ACTUALLY RUN?** Chart of accounts first, then a mapping from the old structure, then bulk import, at balance level or full transaction history, while live events stream in parallel. **WHAT IF THE TWO LEDGERS DISAGREE?** That is the point of the shadow run: continuous reconciliation surfaces every difference before cutover, so the switch happens on proof, not hope. **CAN WE BUILD OUR OWN TOOLS ON TOP?** Yes: everything is API-first with real-time events, so AR portals, approval workflows, and dashboards build against the ledger directly. ## Closing *GET STARTED* ## Modernize on proof, not hope See how Formance fits your migration: book a demo or start building. --- *Lite summary of [Ledger Modernization](https://www.formance.com/solutions/corporate-treasury/ledger-modernization). Request with `Accept: text/markdown` for this view.* --- title: Multi-Entity Accounting description: "Money arrives addressed to the group and must land in the right subsidiary, business unit, and cost center. Every acquisition adds entities, every restructure re-keys cost centers, and the GL absorbs it in batches, months behind reality." canonical: "https://www.formance.com/solutions/corporate-treasury/multi-entity-accounting" type: solution-lite updated: "2026-07-28T15:58:57.376Z" --- *MULTI-ENTITY ACCOUNTING* # Every entity, every cost center, one ledger Attribute every dollar to the right company and cost center across a growing group, and keep it right through acquisitions, restructures, and consolidation. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## The org chart moves faster than the GL ### Acquisitions and restructures break entity-level accounting. Money arrives addressed to the group and must land in the right subsidiary, business unit, and cost center. Every acquisition adds entities, every restructure re-keys cost centers, and the GL absorbs it in batches, months behind reality. > A serial acquirer runs entity and cost-center attribution on Formance across dozens of operating companies. - Payments default to the wrong entity, and reallocation is a manual journal entry. - Restructuring a cost center means re-keying history transaction by transaction. - Each acquisition arrives with its own systems, and integration takes quarters. - Roll-up reporting across entities and cost centers is a spreadsheet exercise, not a query. ## Flow of funds *FLOW OF FUNDS* ## Group money, entity truth ### Attributed at posting, not reallocated at close. Every transaction posts with its customer, company, and cost-center dimensions from day one, so entity positions, intercompany balances, and group roll-ups are derived live, not assembled at month-end. *entity attribution* - group inflow: payment received - attribution: entity · cost center - intercompany: cross-entity flows - roll-up: group consolidation ## Capabilities *CAPABILITIES* ## The primitives groups need ### Built on the open-source Formance ledger. Dimensional account structures, intercompany flows, and bulk restructuring, composed for multi-entity groups. - **DIMENSIONAL ACCOUNTS** — Accounts structured by customer, company, and cost center: every posting carries its dimensions, every balance rolls up along any of them. - roll-up any axis - **INTERCOMPANY FLOWS** — Cross-entity movements post both sides atomically, so intercompany balances always net and eliminations are derived, not hunted. - always-balanced IC - **BULK RESTRUCTURING** — Re-key cost centers and merge entities with bulk operations across committed history: a restructure is a mapping, not a re-keying project. - history-safe re-keys - **ACQUISITION ONBOARDING** — Bring an acquired company's books in through a mapped migration: shadow-run against their system, then cut over with the history intact. - mapped migrations ## Metrics *BY THE NUMBERS* ## Group-grade, by design - **live** — entity positions - **atomic** — intercompany postings - **bulk** — restructuring operations - **any** — reporting roll-up ## Code *NUMSCRIPT* ## Attribution happens at posting ### Customer, company, and cost center, in the account itself. The account structure carries the dimensions: one posting records which customer owes which company for work done by which cost center, and every roll-up follows. ## FAQ **HOW DO COST-CENTER RESTRUCTURES WORK?** As bulk operations: a mapping (say B.0313 → B.0314) applies across accounts and metadata without hand-editing history, and the change itself is auditable. **HOW FAST CAN AN ACQUISITION BE ONBOARDED?** Once the chart of accounts mapping is defined, the acquired books migrate through bulk endpoints: shadow-run alongside their system, then cut over. Weeks, not quarters. **DO INTERCOMPANY BALANCES ALWAYS NET?** Yes: cross-entity flows post both legs in one atomic transaction, so intercompany positions are equal and opposite by construction, and eliminations are a query. **CAN REPORTING ROLL UP ACROSS DIMENSIONS?** Yes. Balances derive along any dimension in the account structure: one customer across all entities, one entity across all customers, one cost center across everything. ## Closing *GET STARTED* ## A group that consolidates itself See how Formance fits your entity structure: book a demo or start building. --- *Lite summary of [Multi-Entity Accounting](https://www.formance.com/solutions/corporate-treasury/multi-entity-accounting). Request with `Accept: text/markdown` for this view.* --- title: Accounts Receivable description: "Payments arrive through lockboxes and card processors, invoices live in the ERP, and matching them is manual: short-pays, early-pay discounts, and cross-currency payments all land unapplied and wait for a human." canonical: "https://www.formance.com/solutions/corporate-treasury/accounts-receivable" type: solution-lite updated: "2026-07-28T15:59:00.518Z" --- *ACCOUNTS RECEIVABLE* # Cash application that applies itself Invoices, lockbox and card payments, discounts, and write-offs: an AR system of record where every payment lands on the right invoice, in the right entity, in the right currency. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Your team touches every payment twice ### Cash application at enterprise scale is rekeying, not accounting. Payments arrive through lockboxes and card processors, invoices live in the ERP, and matching them is manual: short-pays, early-pay discounts, and cross-currency payments all land unapplied and wait for a human. > A North American environmental services leader runs its AR system of record on Formance, from invoice to applied cash. - Card and lockbox payments are double-touched and rekeyed before they apply. - A USD payment against a CAD balance sits unapplied until someone does FX by hand. - Small-balance write-offs and early-pay discounts are policies in someone's head, not rules in the system. - Every correction and adjustment must be traceable for SOX, and reconstructing them is archaeology. ## Flow of funds *FLOW OF FUNDS* ## From invoice to applied cash ### Billed, collected, applied, and cleared: one double-entry chain. An invoice opens the receivable, the payment arrives through a lockbox or processor, application matches it to the invoice (discounts and tolerable short-pays posting as explicit rules), and the residual clears by policy, not by hand. *applied vs unapplied* - invoice: receivable opened - payment: lockbox · card - application: matched to invoice - residual: discount · write-off ## Capabilities *CAPABILITIES* ## The primitives AR teams need ### Built on the open-source Formance ledger. Event-driven receivables, rule-based application, and native multi-currency, composed for enterprise order-to-cash. - **RECEIVABLES LEDGER** — Invoices, payments, and adjustments posted as double-entry events from your OMS and ERP; balances derived per customer, invoice, entity, and cost center. - roll-up any dimension - **CASH APPLICATION** — Lockbox and processor receipts matched to open invoices by rule: exact, partial, and short-pay scenarios post deterministically, no rekeying. - no double-touch - **DISCOUNTS & WRITE-OFFS** — Early-pay discounts and small-balance tolerances declared as Numscript policies: applied consistently, approved by role, auditable forever. - policy, not habit - **NATIVE MULTI-CURRENCY** — CAD and USD (or any pair) held natively per account; cross-currency application posts with an explicit conversion, never a mental FX step. - explicit FX legs ## Metrics *BY THE NUMBERS* ## Order-to-cash, by design - **0** — rekeyed payments - **any** — roll-up dimension - **native** — multi-currency AR - **100%** — correction traceability ## Code *NUMSCRIPT* ## Application is a rule, not a task ### Payment applied, discount honored, residual written off: one transaction. One Numscript transaction applies the lockbox payment to the invoice, honors the early-pay discount, and clears the residual within tolerance, every leg explicit and auditable. ## FAQ **DOES FORMANCE CREATE THE INVOICES?** No: it is the AR system of record, not the billing application. Your OMS and billing systems emit events; the ledger records them in double-entry and derives every balance. **HOW DO SHORT-PAYS AND TOLERANCES WORK?** Tolerances and dealer terms are declared rules: a payment within tolerance applies and the residual writes off automatically, with the policy and the posting both auditable. **WHAT ABOUT CROSS-CURRENCY PAYMENTS?** A USD payment against a CAD invoice posts with an explicit conversion leg at a booked rate: applied immediately, no unapplied queue, both currencies exact. **IS IT SOX-AUDITABLE?** Yes: every posting, correction, and write-off is immutable and hash-linked, with role-based approval upstream, so the audit trail is the record itself. ## Closing *GET STARTED* ## Close the books without touching the payments See how Formance fits your order-to-cash: book a demo or start building. --- *Lite summary of [Accounts Receivable](https://www.formance.com/solutions/corporate-treasury/accounts-receivable). Request with `Accept: text/markdown` for this view.* --- title: On-Demand description: "Each completed job splits a fare across the worker, the platform, taxes, and sometimes a fleet partner, at volume, in real time, with workers cashing out instantly. Batch-computed earnings cannot keep up, and support drowns in balance disputes." canonical: "https://www.formance.com/solutions/vertical-saas/on-demand" type: solution-lite updated: "2026-07-28T15:59:03.668Z" --- *ON-DEMAND* # Split every ride, every delivery, in real time Fares, courier earnings, tips, surge, and instant cash-outs: a ledger fast enough for on-demand volume and exact enough for everyone's cut. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Every trip is a settlement event ### Millions of micro-splits a day, and every worker checks their balance. Each completed job splits a fare across the worker, the platform, taxes, and sometimes a fleet partner, at volume, in real time, with workers cashing out instantly. Batch-computed earnings cannot keep up, and support drowns in balance disputes. > On-demand platforms run earnings and instant payouts on Formance at marketplace scale. - Worker earnings are recomputed in nightly batches, so in-app balances lag reality. - Instant cash-outs race against uncomputed earnings and go negative. - Surge pricing, incentives, and tips complicate every split differently. - Fleet partners and multi-city tax rules multiply the settlement logic. ## Flow of funds *FLOW OF FUNDS* ## From fare to instant cash-out ### Split at completion, available immediately, paid out on demand. The rider's fare splits at trip completion (platform take, taxes, worker earnings), and the worker's balance is live the moment the trip ends. Instant cash-out debits a real balance, not an estimate. *live earnings* - fare: rider charged - split: platform · tax · worker - earnings: live balance - cash-out: instant payout ## Capabilities *CAPABILITIES* ## The primitives on-demand platforms need ### Built on the open-source Formance ledger. Real-time fare splits, live worker balances, and safe instant payouts, composed for high-frequency operations. - **REAL-TIME SPLITS** — Fare, surge, tips, taxes, and incentives split at trip completion in one atomic transaction, at thousands per second. - atomic at volume - **LIVE EARNINGS** — Worker balances derived from the log, surfaced in-app the second a job completes: no nightly batch, no disputes. - balance = truth - **INSTANT CASH-OUT** — Payouts debit real balances with overdraft protection built into the ledger: a race condition cannot overdraw a worker. - safe by construction - **FLEET & TAX LOGIC** — Fleet partner shares and per-city tax rules declared per market: expansion is configuration, not a settlement rewrite. - per-market rules ## Metrics *BY THE NUMBERS* ## On-demand-grade, by design - **1000s** — splits per second - **live** — worker balances - **0** — overdrawn cash-outs - **per market** — split logic ## Code *NUMSCRIPT* ## The fare splits at completion ### Worker paid, platform paid, tax set aside: one transaction. Trip completion posts one Numscript transaction: the rider's fare splits across the worker's live balance, the platform take, and the tax account, atomically, at volume. ## FAQ **CAN IT HANDLE OUR PEAK VOLUME?** Yes: the ledger sustains thousands of transactions per second per ledger, so splits post at trip completion even through the Friday-night peak. **HOW DO INSTANT CASH-OUTS STAY SAFE?** Cash-outs debit derived balances with ledger-enforced constraints: a concurrent trip and cash-out cannot overdraw the worker, by construction. **WHAT ABOUT INCENTIVES AND SURGE?** Bonuses, guarantees, and surge multipliers are declared transaction patterns: they post through the same split, visible in the worker's history like any earning. **HOW DO FLEET PARTNERS GET PAID?** Fleet shares are part of the declared split per market; partner payables accrue in real time and settle on schedule, derived from the same record. ## Closing *GET STARTED* ## Settlement at the speed of dispatch See how Formance fits your on-demand platform: book a demo or start building. --- *Lite summary of [On-Demand](https://www.formance.com/solutions/vertical-saas/on-demand). Request with `Accept: text/markdown` for this view.* --- title: Healthcare description: "A single visit collects a co-pay today, bills an insurer that pays in weeks, and settles the provider net of platform fees, while claims get adjusted, denied, and resubmitted. Matching cash to care is a full-time job." canonical: "https://www.formance.com/solutions/vertical-saas/healthcare" type: solution-lite updated: "2026-07-28T15:59:06.813Z" --- *HEALTHCARE* # Patient, insurer, provider: one payment record Split payments across patients and payers, settle providers on time, and reconcile claims to cash on a single auditable ledger. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## One appointment, three payers, months of settlement ### Healthcare payments split across parties that settle at different speeds. A single visit collects a co-pay today, bills an insurer that pays in weeks, and settles the provider net of platform fees, while claims get adjusted, denied, and resubmitted. Matching cash to care is a full-time job. > Healthcare platforms run patient-to-provider flows on Formance, claims matched to cash continuously. - Patient co-pays and insurer portions for the same visit live in different systems. - Insurer remittances arrive weeks later, batched, and rarely match the claims sent. - Provider payouts are computed from spreadsheets that lag adjustments and denials. - Refunds and claim reversals restate money that was already settled. ## Flow of funds *FLOW OF FUNDS* ## From visit to provider settlement ### Co-pay now, insurer later, provider paid from both. The co-pay posts at the visit, the insurer receivable tracks the claim until remittance lands and matches, and the provider's payable accrues from both, net of fees, settled on schedule. *claims-to-cash* - co-pay: patient pays - receivable: insurer claim - remittance: matched to claim - provider payout: net settlement ## Capabilities *CAPABILITIES* ## The primitives healthcare platforms need ### Built on the open-source Formance ledger. Multi-payer visit accounting, claims-aware receivables, and derived provider settlement, composed for care platforms. - **MULTI-PAYER VISITS** — Patient, insurer, and subsidy portions of one visit tracked as linked postings on a single encounter. - one visit, one record - **CLAIMS RECEIVABLES** — Claims as explicit receivables with lifecycle states (submitted, adjusted, denied, paid), always reconciled to cash. - claims-to-cash - **PROVIDER SETTLEMENT** — Provider payables derived from co-pays and remittances net of fees, settled on schedule; statements come straight from the log. - derived payouts - **REMITTANCE MATCHING** — Batched insurer remittances normalize and match against open receivables continuously, flagging underpayments immediately. - underpayments flagged ## Metrics *BY THE NUMBERS* ## Care-grade accounting, by design - **per visit** — payment traceability - **continuous** — remittance matching - **derived** — provider payouts - **100%** — adjustment history ## Code *NUMSCRIPT* ## A visit posts both payers at once ### Co-pay collected, insurer receivable opened: one operation. One Numscript transaction records the patient's co-pay and opens the insurer receivable for the balance of the visit, both linked to the same encounter. ## FAQ **HOW DO DENIED OR ADJUSTED CLAIMS POST?** Denials and adjustments restate the receivable as explicit transactions: the encounter's history shows every version, and provider payables adjust automatically. **CAN REMITTANCES MATCH AUTOMATICALLY?** Yes: batched remittances normalize through Connectivity and match against open receivables by claim reference, with underpayments flagged for follow-up. **HOW ARE PROVIDER PAYOUTS COMPUTED?** Payables derive in real time from collected co-pays and matched remittances, net of declared platform fees; the payout pays what the ledger holds. **IS PATIENT DATA IN THE LEDGER?** The ledger stores financial postings and references, not clinical data: encounters link by identifier, keeping the money record clean of PHI. ## Closing *GET STARTED* ## Match every claim to its cash See how Formance fits your healthcare platform: book a demo or start building. --- *Lite summary of [Healthcare](https://www.formance.com/solutions/vertical-saas/healthcare). Request with `Accept: text/markdown` for this view.* --- title: Hospitality description: "A stay collects a deposit months ahead, modifies twice, splits across the OTA, the property, and the tax office, and might refund in another currency. PMS data, PSP events, and bank statements each tell a different story." canonical: "https://www.formance.com/solutions/vertical-saas/hospitality" type: solution-lite updated: "2026-07-28T15:59:09.955Z" --- *HOSPITALITY* # Every booking, every party, every currency — balanced Deposits, OTA commissions, city taxes, no-show fees, and property payouts: one ledger for the money side of every stay. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## A booking is a payment plan with five stakeholders ### Deposits, modifications, and multi-party splits stress-test any payment stack. A stay collects a deposit months ahead, modifies twice, splits across the OTA, the property, and the tax office, and might refund in another currency. PMS data, PSP events, and bank statements each tell a different story. > Hospitality platforms run booking-to-payout flows on Formance across properties and currencies. - Deposits and prepayments sit as liabilities nobody tracks until check-in. - OTA commissions, city taxes, and platform fees split differently per channel and market. - Modifications, no-shows, and cancellations restate money already collected. - Multi-currency guests and properties make reconciliation a monthly forensic exercise. ## Flow of funds *FLOW OF FUNDS* ## From booking to property payout ### Collected as a liability, earned at stay, split at settlement. The deposit posts as a guest liability, check-in converts it to earned revenue through the channel's split (commission, taxes, property share), and the property payout pays the derived balance, in its currency. *booking liability* - deposit: guest prepays - liability: held until stay - split: OTA · tax · property - payout: property settled ## Capabilities *CAPABILITIES* ## The primitives hospitality platforms need ### Built on the open-source Formance ledger. Liability-aware booking flows, per-channel splits, and multi-currency settlement, composed for stays at scale. - **BOOKING LIABILITIES** — Deposits and prepayments tracked as explicit liabilities per booking, converting to revenue at stay, restated cleanly on every modification. - liability-aware - **CHANNEL SPLITS** — OTA commissions, city taxes, and platform fees declared per channel and market, applied atomically at settlement. - per-channel logic - **MULTI-CURRENCY** — Guest currency in, property currency out: FX conversions posted as explicit transactions with the spread accounted. - explicit FX - **PSP & OTA RECONCILIATION** — PSP settlements and OTA statements normalize and match continuously against per-booking ledger state. - per-booking matching ## Metrics *BY THE NUMBERS* ## Hospitality-grade, by design - **per booking** — money traceability - **any** — channel split - **multi** — currency settlement - **continuous** — PSP reconciliation ## Code *NUMSCRIPT* ## Check-in settles the booking ### Liability becomes revenue, split across every party. At check-in, one Numscript transaction converts the guest's prepaid liability through the channel split (OTA commission, city tax, and the property's payable), atomically. ## FAQ **HOW ARE MODIFICATIONS AND CANCELLATIONS HANDLED?** Each modification posts as a restating transaction against the booking's liability: partial refunds, date changes, and no-show fees keep a complete history. **CAN SPLITS DIFFER PER CHANNEL AND MARKET?** Yes: OTA terms, tax rates, and platform fees are declared per channel and market, so a new OTA contract or city tax is configuration, not code. **HOW DOES MULTI-CURRENCY SETTLEMENT WORK?** The guest pays in their currency, the property settles in its own, and the conversion posts explicitly with its rate and spread; both sides reconcile in their books. **CAN PROPERTIES SEE THEIR POSITION?** Yes: per-property payables derive in real time from stays, refunds, and adjustments, so owner statements come from the ledger, not a spreadsheet export. ## Closing *GET STARTED* ## Money flows as smooth as check-in See how Formance fits your hospitality platform: book a demo or start building. --- *Lite summary of [Hospitality](https://www.formance.com/solutions/vertical-saas/hospitality). Request with `Accept: text/markdown` for this view.* --- title: Marketplace description: "A sale is a buyer payment, an escrow period, a commission, sometimes a shipping split, then a payout, and a refund can interrupt any step. PSP balances tell you the total; they cannot tell you whose money it is." canonical: "https://www.formance.com/solutions/vertical-saas/marketplace" type: solution-lite updated: "2026-07-28T15:59:13.184Z" --- *MARKETPLACE* # Split every sale, hold every escrow, pay every seller Buyer payments, escrow holds, fee splits, refunds, and seller payouts: one ledger keeps every party's position exact across all of it. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Marketplace money has too many owners ### Between buyer and seller, funds pass through states your PSP does not track. A sale is a buyer payment, an escrow period, a commission, sometimes a shipping split, then a payout, and a refund can interrupt any step. PSP balances tell you the total; they cannot tell you whose money it is. > Marketplaces run seller balances and escrow on Formance, with payouts derived from the ledger. - Funds held between sale and delivery belong to no one system: escrow is a database flag. - Commission, shipping, and promo splits are hard-coded and change with every category. - Refunds after payout drive seller balances negative, and recovery is manual. - Seller payout questions ("where is my money?") take support tickets to answer. ## Flow of funds *FLOW OF FUNDS* ## From checkout to seller payout ### Escrowed at purchase, split at release, paid on schedule. The buyer's payment lands in escrow, delivery releases it through the declared split (commission to the platform, remainder to the seller's payable), and payouts pay exactly what the ledger holds. Refunds reverse the same path. *seller position* - checkout: buyer pays - escrow: held until delivery - split: commission · seller - payout: seller settled ## Capabilities *CAPABILITIES* ## The primitives marketplaces need ### Built on the open-source Formance ledger. Native escrow, declarative splits, and derived seller payouts, composed for multi-party commerce. - **ESCROW ACCOUNTS** — Funds held between purchase and release live in real ledger accounts with explicit states, not a boolean on an orders table. - real escrow - **DECLARATIVE SPLITS** — Commission, shipping, promos, and taxes declared in Numscript per category or seller tier, changed by configuration rather than release. - per-category splits - **SELLER BALANCES** — Every seller's payable derived from sales, refunds, and adjustments in real time, surfaced in the seller dashboard straight from the ledger. - self-serve answers - **PSP RECONCILIATION** — Captures, refunds, and payout files from every PSP normalize and match continuously against ledger state. - multi-PSP, one truth ## Metrics *BY THE NUMBERS* ## Marketplace-grade, by design - **exact** — seller positions - **native** — escrow states - **any** — split logic - **fewer** — payout tickets ## Code *NUMSCRIPT* ## Release escrow through the split ### Delivery confirmed, everyone paid their share, atomically. When delivery confirms, one Numscript transaction releases the escrowed payment through the declared split: platform commission out, seller payable credited. ## FAQ **WHAT HAPPENS ON A REFUND AFTER PAYOUT?** The refund debits the seller's payable as a ledger transaction. A negative position nets against future sales, tracked automatically rather than chased manually. **CAN SPLITS DIFFER BY CATEGORY OR SELLER TIER?** Yes: splits are declared per category, tier, or even per listing. New commercial terms are configuration, applied atomically from the next transaction. **DOES ESCROW WORK WITH OUR PSP?** Yes: the PSP moves the money; the ledger tracks whose it is and what state it is in. Escrow, release, and refund are ledger states reconciled against PSP events. **CAN SELLERS SEE THEIR OWN BALANCE?** Yes: seller dashboards read derived balances straight from the ledger (sales, fees, refunds, and upcoming payouts) without a support ticket. ## Closing *GET STARTED* ## Every party paid, every cent provable See how Formance fits your marketplace: book a demo or start building. --- *Lite summary of [Marketplace](https://www.formance.com/solutions/vertical-saas/marketplace). Request with `Accept: text/markdown` for this view.* --- title: Insurance description: "A single premium splits across commissions, taxes, carrier shares, and reinsurance cessions, then flows back out as claims and refunds months later. Tracked across bordereaux and spreadsheets, the money and the paperwork stop agreeing." canonical: "https://www.formance.com/solutions/fintech/insurance" type: solution-lite updated: "2026-07-28T15:59:16.421Z" --- *INSURANCE* # Premiums in, claims out, nothing unaccounted Track premium collection, commission splits, claims payouts, and carrier settlement on one ledger, across brokers, carriers, and reinsurers. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Premium money touches five hands before it settles ### Broker, platform, carrier, reinsurer — everyone needs their exact share. A single premium splits across commissions, taxes, carrier shares, and reinsurance cessions, then flows back out as claims and refunds months later. Tracked across bordereaux and spreadsheets, the money and the paperwork stop agreeing. > Insurance platforms run premium and claims flows on Formance, every split posted at collection. - Premium splits — commission, tax, carrier share — are computed in spreadsheets per bordereau. - Client money and carrier money mix in the same accounts with no provable segregation. - Claims reserves and payouts are tracked separately from the premium that funds them. - Carrier and reinsurer settlement happens monthly, by hand, from exported CSVs. ## Flow of funds *FLOW OF FUNDS* ## From premium to claim, one chain ### Split at collection, settled by schedule, claims from reserves. Each premium splits at collection (commission, taxes, carrier share) into segregated accounts. Carrier settlement pays what the ledger holds, and claims draw from reserves with the full policy history attached. *client-money segregation* - premium: collected - split: commission · tax · carrier - reserves: claims funded - settlement: carrier · reinsurer ## Capabilities *CAPABILITIES* ## The primitives insurance platforms need ### Built on the open-source Formance ledger. Declarative premium splits, segregated client money, and scheduled carrier settlement, composed for insurance distribution. - **PREMIUM SPLITS** — Commissions, taxes, and carrier shares declared in Numscript and posted at collection: per product, per broker, per carrier. - split at collection - **CLIENT-MONEY SEGREGATION** — Premium held for carriers stays in segregated account trees, provable at any timestamp for CASS-style reviews. - provable segregation - **CLAIMS & RESERVES** — Reserves funded, adjusted, and drawn as ledger transactions linked to their policies; payouts trace to the premiums that funded them. - policy-linked claims - **CARRIER SETTLEMENT** — Bordereau-ready statements derived from the log, and settlement flows to carriers and reinsurers run on schedule. - bordereau from the log ## Metrics *BY THE NUMBERS* ## Insurance-grade, by design - **at collection** — premium splits - **100%** — client-money segregation - **policy-linked** — claims traceability - **scheduled** — carrier settlement ## Code *NUMSCRIPT* ## The premium splits itself ### Commission, tax, and carrier share: one atomic posting. A collected premium distributes across the platform commission, insurance premium tax, and the carrier's segregated account in a single Numscript transaction. ## FAQ **HOW ARE MID-TERM ADJUSTMENTS AND REFUNDS HANDLED?** Endorsements, cancellations, and refunds post as reversing transactions through the same split logic: every party's share adjusts atomically, with history intact. **CAN SPLITS VARY BY PRODUCT AND CARRIER?** Yes: splits are declared per product, broker, and carrier. A new scheme or commission structure is configuration, not a code change. **HOW DOES CARRIER SETTLEMENT WORK?** Carrier and reinsurer positions accrue in segregated accounts as premiums post. Settlement pays the derived balance on schedule, with a bordereau-ready statement from the log. **WHAT ABOUT CLAIMS FUNDED ACROSS REINSURERS?** Reserves and cessions are attributed per treaty, so a claim draws proportionally and every reinsurer's exposure is a ledger fact. ## Closing *GET STARTED* ## Insurance money that stays accounted for See how Formance fits your distribution stack: book a demo or start building. --- *Lite summary of [Insurance](https://www.formance.com/solutions/fintech/insurance). Request with `Accept: text/markdown` for this view.* --- title: Investing description: "Client money and assets pool in nominee and omnibus accounts at custodians and brokers, while each investor expects an exact position. Orders settle T+2, dividends fan out across thousands, and CASS-style audits ask for proof your database cannot give." canonical: "https://www.formance.com/solutions/fintech/investing" type: solution-lite updated: "2026-07-28T15:59:19.670Z" --- *INVESTING* # Nominee accounts with per-investor truth Track every investor's cash and holdings inside pooled nominee accounts: orders, settlement, dividends, and fees, all on one auditable record. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Pooled accounts, individual promises ### Every investor's statement is a claim you must be able to prove. Client money and assets pool in nominee and omnibus accounts at custodians and brokers, while each investor expects an exact position. Orders settle T+2, dividends fan out across thousands, and CASS-style audits ask for proof your database cannot give. > Shares runs its investing infrastructure on Formance, attributing pooled positions per investor. - Client money pools at brokers and banks with per-investor attribution living in app code. - Order execution and T+2 settlement drift apart, and cash appears or vanishes for days. - Dividends, splits, and fees fan out across thousands of investors in batch scripts. - Client-money audits demand point-in-time segregation proofs that take weeks to build. ## Flow of funds *FLOW OF FUNDS* ## From order to settled holding ### Cash reserved at order, holdings posted at settlement, attributed throughout. An order reserves the investor's cash, execution converts it into a pending position, settlement posts the holding, and corporate actions fan out atomically, with the nominee account sub-ledgered per investor at every step. *client-money segregation* - order: cash reserved - execution: pending position - settlement: holding posted - custody: nominee, sub-ledgered ## Capabilities *CAPABILITIES* ## The primitives investment platforms need ### Built on the open-source Formance ledger. Sub-ledgered nominee accounts, settlement-aware order flows, and atomic corporate actions, composed for retail investing. - **NOMINEE SUB-LEDGERING** — Per-investor cash and holdings inside pooled nominee and omnibus accounts, exact at any timestamp. - per-investor attribution - **ORDER & SETTLEMENT FLOWS** — Reserve, execute, settle: T+2 timing modeled explicitly, so cash and positions never silently disagree. - settlement-aware - **CORPORATE ACTIONS** — Dividends, splits, and fee sweeps posted atomically across every affected investor in one operation. - atomic fan-out - **CUSTODIAN RECONCILIATION** — Match broker and custodian statements against the ledger continuously; client-money reports reproduce for any date. - audit-ready ## Metrics *BY THE NUMBERS* ## Investing-grade, by design - **100%** — position attribution - **T+2** — settlement modeled - **atomic** — corporate actions - **any date** — client-money proofs ## Code *NUMSCRIPT* ## A dividend fans out atomically ### Thousands of investors, one auditable operation. A dividend arrives at the nominee account and distributes to every holder pro-rata in one atomic posting: no batch script, no partial state, full audit trail. ## FAQ **HOW IS CLIENT MONEY SEGREGATED?** Client cash lives in segregated account trees sub-ledgered per investor, reconciled continuously against the banks and brokers that hold it, provable for any date. **WHAT HAPPENS BETWEEN EXECUTION AND SETTLEMENT?** Pending positions are explicit: cash is reserved at order, the position posts as pending at execution, and settlement converts it; nothing appears or vanishes. **CAN FRACTIONAL SHARES BE TRACKED?** Yes: assets are ledgered with configurable precision, so fractional holdings carry the same double-entry guarantees as whole units. **HOW DO YOU HANDLE MULTIPLE BROKERS AND CUSTODIANS?** Statements normalize into one schema and reconcile against ledger state continuously: one investor position across every venue, one audit trail. ## Closing *GET STARTED* ## Positions you can prove, investor by investor See how Formance fits your investing stack: book a demo or start building. --- *Lite summary of [Investing](https://www.formance.com/solutions/fintech/investing). Request with `Accept: text/markdown` for this view.* --- title: Lending description: "Every repayment splits across fees, interest, and principal, differently per product, per delinquency state, per funding source. Hard-coded waterfall logic drifts from the loan agreements, and audits become archaeology." canonical: "https://www.formance.com/solutions/fintech/lending" type: solution-lite updated: "2026-07-28T15:59:23.057Z" --- *LENDING* # From disbursement to final repayment, one immutable trail Run disbursements, repayment waterfalls, and investor attribution on a ledger that keeps every loan's position exact for its entire life. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## A loan book is a thousand tiny waterfalls ### Splitting repayments by hand is how books drift. Every repayment splits across fees, interest, and principal, differently per product, per delinquency state, per funding source. Hard-coded waterfall logic drifts from the loan agreements, and audits become archaeology. > Liberis runs embedded lending on Formance and closed the gap to zero reconciliation errors. - Repayment waterfalls are hard-coded, and edge cases (early, partial, late) corrupt loan positions. - Outstanding principal and accrued interest are recomputed in batch, never live. - Investor and warehouse funding cannot be attributed cleanly across the book. - The audit trail from disbursement to write-off lives across three systems. ## Flow of funds *FLOW OF FUNDS* ## Disburse once, track forever ### Funding out, repayments in, every split explicit. The disbursement draws from its funding source, each repayment splits across fees, interest, and principal by the declared waterfall, and the loan position is derived live, not recomputed nightly. *loan position* - disbursement: funding → borrower - loan account: live position - repayment: waterfall split - investors: attributed returns ## Capabilities *CAPABILITIES* ## The primitives lenders need ### Built on the open-source Formance ledger. Declarative waterfalls, live loan positions, and funding attribution, composed for lending at scale. - **REPAYMENT WATERFALLS** — Fees, interest, and principal split declared in Numscript per product: early, partial, and late payments post deterministically. - declarative splits - **LIVE LOAN POSITIONS** — Outstanding principal, accrued interest, and arrears derived from the log in real time: per loan, per cohort, per book. - derived, not batch - **FUNDING ATTRIBUTION** — Attribute every disbursement and repayment to its warehouse line or investor, with returns computed from the same record. - per-investor truth - **COLLECTION RECONCILIATION** — Match PSP collections and bank deposits against expected repayments continuously, surfacing misses the day they happen. - same-day arrears ## Metrics *BY THE NUMBERS* ## Lending-grade, by design - **0** — reconciliation errors - **live** — loan positions - **100%** — disbursement-to-close trail - **any** — waterfall ## Code *NUMSCRIPT* ## The waterfall is declared, not coded ### Fees, then interest, then principal, in one transaction. A repayment posts through the declared waterfall: fees first, accrued interest second, principal last: atomically, with the loan position updated by construction. ## FAQ **HOW DO EARLY OR PARTIAL REPAYMENTS POST?** Through the same declared waterfall: the split adapts to the amount and the loan's state, and the position updates atomically. No special-case code paths. **CAN I SEE OUTSTANDING PRINCIPAL LIVE?** Yes. Positions are derived from the transaction log in real time (per loan, per cohort, or across the book) and reproducible for any past date. **HOW IS INVESTOR FUNDING ATTRIBUTED?** Each disbursement draws from an attributed funding account, and repayments flow back through the same attribution: returns per investor are ledger facts, not spreadsheet estimates. **WHAT ABOUT DELINQUENCY AND WRITE-OFFS?** State changes post as explicit transactions (arrears, restructuring, write-off), so the full lifecycle of every loan is one continuous, auditable history. ## Closing *GET STARTED* ## Lend on a book that balances itself See how Formance fits your lending stack: book a demo or start building. --- *Lite summary of [Lending](https://www.formance.com/solutions/fintech/lending). Request with `Accept: text/markdown` for this view.* --- title: Acquiring description: "Every merchant's payable is captures minus fees, minus refunds, minus chargebacks, minus the rolling reserve, computed across processors and settlement files that disagree. Get it wrong and you pay out money you do not have." canonical: "https://www.formance.com/solutions/fintech/acquiring" type: solution-lite updated: "2026-07-28T15:59:26.218Z" --- *ACQUIRING* # Merchant settlement that adds up, every day Run fee schedules, rolling reserves, and payout cycles on a ledger that keeps every merchant's position exact — through chargebacks, refunds, and everything else. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## A merchant balance is a moving target ### Captures, refunds, chargebacks, and reserves all pull in different directions. Every merchant's payable is captures minus fees, minus refunds, minus chargebacks, minus the rolling reserve, computed across processors and settlement files that disagree. Get it wrong and you pay out money you do not have. > Acquirers and payment facilitators run merchant settlement on Formance, every payout derived, never estimated. - Merchant payables are computed in batch jobs that nobody can audit after the fact. - Fee schedules (per merchant, per method, per volume tier) live in brittle application code. - Chargebacks and refunds land after payout, driving merchant balances negative. - Rolling reserves are tracked in spreadsheets next to the real books. ## Flow of funds *FLOW OF FUNDS* ## From shopper capture to merchant payout ### Fees, reserve, and payable split at capture: payout is just a query. Each capture credits the merchant's payable net of fees, sets aside the rolling reserve, and the payout cycle simply pays what the ledger says. Refunds and chargebacks debit the same accounts, so the position is always current. *merchant position* - capture: shopper payment - fee split: schedule applied - reserve: rolling hold - payout: merchant settled ## Capabilities *CAPABILITIES* ## The primitives acquirers need ### Built on the open-source Formance ledger. Declarative fee schedules, native reserve management, and processor reconciliation, composed for merchant settlement. - **MERCHANT ACCOUNTS** — A payable position per merchant derived from every capture, refund, and chargeback: exact at any moment, auditable forever. - derived payables - **FEE SCHEDULES** — Per-merchant, per-method, tiered pricing declared in Numscript and applied at capture, not reconstructed in a batch job. - declarative pricing - **ROLLING RESERVES** — Reserves held, released, and drawn as ledger transactions with their own account trees and release schedules. - native reserves - **PROCESSOR RECONCILIATION** — Settlement files from processors and schemes match continuously against ledger state, with breaks flagged same-day. - same-day breaks ## Metrics *BY THE NUMBERS* ## Settlement-grade, by design - **exact** — merchant positions - **any** — fee schedule - **daily** — payout cycles - **same-day** — settlement breaks ## Code *NUMSCRIPT* ## The split happens at capture ### Fees and reserve are accounting, not a nightly job. One Numscript transaction credits the merchant net of the fee schedule and sets aside the rolling reserve; the payout cycle later pays exactly what the ledger holds. ## FAQ **HOW ARE CHARGEBACKS HANDLED AFTER PAYOUT?** Chargebacks debit the merchant's payable (or reserve) as ledger transactions. If the position goes negative, it nets against future captures, tracked rather than lost. **CAN FEE SCHEDULES DIFFER PER MERCHANT?** Yes: pricing is declared per merchant, per payment method, and per volume tier, and applied atomically at capture. Changing a schedule is configuration, not a migration. **HOW DO ROLLING RESERVES RELEASE?** Reserves are held in per-merchant accounts with release schedules run as workflows: held, released, and drawn amounts are all auditable ledger history. **WHAT ABOUT MULTIPLE PROCESSORS?** Captures and settlement files from every processor normalize into one schema, so merchant positions aggregate across processors and reconcile continuously. ## Closing *GET STARTED* ## Pay out what you can prove See how Formance fits your settlement stack: book a demo or start building. --- *Lite summary of [Acquiring](https://www.formance.com/solutions/fintech/acquiring). Request with `Accept: text/markdown` for this view.* --- title: Card Issuing description: "An authorization must check and hold funds inside the network's window, then survive captures that arrive days later, partial reversals, and settlement files that never quite match. Most home-built ledgers fail on both speed and truth." canonical: "https://www.formance.com/solutions/fintech/card-issuing" type: solution-lite updated: "2026-07-28T15:59:29.438Z" --- *CARD ISSUING* # Authorize in milliseconds, account for every swipe Run the full card lifecycle (authorization, capture, reversal, refund) on a ledger fast enough for the auth window and exact enough for the network files. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## The auth window does not wait for your database ### Card programs live and die on balance checks under one second. An authorization must check and hold funds inside the network's window, then survive captures that arrive days later, partial reversals, and settlement files that never quite match. Most home-built ledgers fail on both speed and truth. > Card programs run authorization balances on Formance, with holds and captures modeled natively. - Authorization checks race against the network window, and latency spikes decline good transactions. - Captures, partial captures, and reversals arrive late and out of order, corrupting balances. - Interchange, program fees, and BIN sponsor splits are hard-coded and unauditable. - Network settlement files reconcile against internal records by hand, at month-end. ## Flow of funds *FLOW OF FUNDS* ## From swipe to settled, one lifecycle ### Authorization holds, capture settles, reversal releases, atomically. The swipe posts a hold against available balance, the capture settles the exact amount and splits fees, and reversals release cleanly. Network settlement reconciles continuously against what the ledger already knows. *auth-to-settlement* - authorization: hold in ms - capture: exact settle - fee split: interchange · program - network settle: files reconciled ## Capabilities *CAPABILITIES* ## The primitives issuers need ### Built on the open-source Formance ledger. Low-latency balance checks, a native card lifecycle, and declarative fee splits, composed for issuing programs. - **REAL-TIME AUTHORIZATION** — Balance checks and holds fast enough for the network auth window, at thousands of transactions per second. - in-window auth - **CARD LIFECYCLE** — Holds, captures, partial captures, reversals, and refunds as native patterns, consistent even when events arrive out of order. - out-of-order safe - **FEE SPLITS** — Interchange, program fees, and sponsor shares modeled declaratively in Numscript, captured at settlement by construction. - declarative splits - **NETWORK RECONCILIATION** — Match network settlement files against ledger state continuously, surfacing breaks the day they happen. - file-level matching ## Metrics *BY THE NUMBERS* ## Issuing-grade, by design - **ms** — authorization checks - **1000s** — transactions per second - **100%** — lifecycle traceability - **daily** — network reconciliation ## Code *NUMSCRIPT* ## Capture settles the hold, splits the fees ### One transaction closes the loop the swipe opened. Capture settles the merchant amount from the hold, routes interchange and program fees to their accounts, and releases any remainder to the cardholder, atomically. ## FAQ **IS IT FAST ENOUGH FOR THE AUTH WINDOW?** Yes: balance checks and holds execute in milliseconds at thousands of transactions per second, sustained, so latency never declines a good swipe. **WHAT ABOUT PARTIAL CAPTURES AND REVERSALS?** The lifecycle is modeled natively: a hold can settle in parts, reverse in parts, and expire: every path posts deterministically, even out of order. **HOW ARE INTERCHANGE AND PROGRAM FEES HANDLED?** Splits are declared in Numscript and captured at settlement in the same atomic transaction, auditable per swipe, not reconstructed at month-end. **CAN WE RECONCILE NETWORK SETTLEMENT FILES?** Yes. Files from the network and BIN sponsor normalize through Connectivity and match continuously against ledger state, with breaks flagged immediately. And agent card programs (single-use, scoped credentials on the network standards) are a natural fit for the same lifecycle: one funded account per agent, ledger-enforced budgets, transaction-level attribution back to the agent and task. ## Closing *GET STARTED* ## Issue on a ledger that makes the window See how Formance fits your card program: book a demo or start building. --- *Lite summary of [Card Issuing](https://www.formance.com/solutions/fintech/card-issuing). Request with `Accept: text/markdown` for this view.* --- title: Neobanks description: "Balances live in the BaaS platform, card events arrive out of order, and your database is a best-effort mirror. Every provider migration, product launch, and safeguarding review runs into the same wall: the record is not yours." canonical: "https://www.formance.com/solutions/fintech/neobanks" type: solution-lite updated: "2026-07-28T15:59:32.594Z" --- *NEOBANKS* # The ledger behind the balance Own your users' balances instead of renting them from a BaaS provider: real-time accounts, card flows, and safeguarding proofs on one system of record. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Your provider owns your source of truth ### A neobank that cannot compute its own balances is an interface, not a bank. Balances live in the BaaS platform, card events arrive out of order, and your database is a best-effort mirror. Every provider migration, product launch, and safeguarding review runs into the same wall: the record is not yours. > Neobanks run user accounts on Formance and surface ledger balances directly in-app. - User balances are a mirror of provider APIs, not a record you own and can prove. - Authorization, settlement, and refund events race each other and drift out of order. - New products (pots, joint accounts, interest) wait on provider roadmaps. - Safeguarding reconciliations against the bank partner are manual and month-end. ## Flow of funds *FLOW OF FUNDS* ## Every account event, one record ### Top-ups, card spend, and transfers post to accounts you own. Deposits credit the user, card authorizations hold funds, captures settle them, and internal transfers move instantly, all in your ledger, reconciled continuously against the banking partner's statements. *safeguarding* - deposit: top-up in - user account: your ledger - card spend: hold → capture - bank partner: reconciled ## Capabilities *CAPABILITIES* ## The primitives neobanks need ### Built on the open-source Formance ledger. Owned user accounts, card-native transaction patterns, and continuous partner reconciliation, composed for consumer banking. - **USER ACCOUNTS** — Balances derived from your own immutable log: real-time in-app, exact at any timestamp, independent of any provider. - provider-independent - **CARD FLOWS** — Authorizations, captures, reversals, and refunds as first-class patterns that stay consistent even out of order. - hold → capture native - **PRODUCT VELOCITY** — Pots, joint accounts, interest, and rewards modeled in Numscript: launch account features without waiting on a provider. - features in days - **PARTNER RECONCILIATION** — Continuous matching against bank partner statements with drift alerts, so safeguarding is a query, not a quarter-end project. - continuous safeguarding ## Metrics *BY THE NUMBERS* ## Banking-grade, by design - **real-time** — user balances - **1000s** — transactions per second - **continuous** — safeguarding reconciliation - **days** — to launch account features ## Code *NUMSCRIPT* ## A card authorization is a hold, not a guess ### Reserve the funds now, settle the exact amount later. An authorization moves funds into a hold account atomically; capture settles the final amount and releases the difference: no negative balances, no race conditions. ## FAQ **DOES FORMANCE REPLACE OUR BAAS PROVIDER?** No: it sits underneath as your system of record. Providers keep moving the money; you own the balances, the history, and the ability to switch. **HOW DO OUT-OF-ORDER CARD EVENTS RESOLVE?** Holds, captures, reversals, and refunds are modeled as explicit transaction states, so late or duplicated webhooks reconcile deterministically instead of corrupting balances. **CAN WE SURFACE LEDGER BALANCES IN THE APP?** Yes: balances are derived in real time and served over the API. What the user sees is the record itself, not a cache that drifts. **HOW DOES SAFEGUARDING REPORTING WORK?** User funds map to segregated account trees reconciled continuously against partner statements. Safeguarding reports reproduce for any date from the immutable log. ## Closing *GET STARTED* ## Own the record behind your product See how Formance fits your banking stack: book a demo or start building. --- *Lite summary of [Neobanks](https://www.formance.com/solutions/fintech/neobanks). Request with `Accept: text/markdown` for this view.* --- title: Crypto Payroll description: "Employer funds arrive in one currency, sit as float across providers, and leave as hundreds of payouts across chains and rails. One failed retry double-pays someone; one missed payout is a support escalation, and the float is earning yield nobody can attribute." canonical: "https://www.formance.com/solutions/digital-assets/crypto-payroll" type: solution-lite updated: "2026-07-28T15:59:35.816Z" --- *CRYPTO PAYROLL* # Pay global teams in stablecoins, account for every cent Run batch payouts across chains and currencies with exactly-once guarantees, attributed float, and books that close themselves. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## A payroll run is a thousand payments that must all be right ### Batch payouts across providers were not designed for retries. Employer funds arrive in one currency, sit as float across providers, and leave as hundreds of payouts across chains and rails. One failed retry double-pays someone; one missed payout is a support escalation, and the float is earning yield nobody can attribute. > Payroll platforms run stablecoin compensation on Formance, every payout exactly-once. - Batch payouts fail partially, and retries risk paying someone twice. - Employer float is scattered across providers with no unified cash position. - Yield earned on float cannot be attributed back to the employers who funded it. - Every payout rail (chains, banks, local partners) has its own integration and its own failure modes. ## Flow of funds *FLOW OF FUNDS* ## One funding, a thousand exact payouts ### Employer money in, attributed float, per-employee payouts out. The employer funds the run, the float holds attributed balances per employer, and the batch fans out to per-employee payouts across rails: each one idempotent, each one traceable back to its funding. *exactly-once payouts* - employer funding: run financed - payroll float: attributed per employer - batch payout: per-employee, idempotent - off-ramp: local currency out ## Capabilities *CAPABILITIES* ## The primitives payroll platforms need ### Built on the open-source Formance ledger. Idempotent batch execution, attributed float, and multi-rail payout connectivity, composed for global compensation. - **BATCH PAYOUTS** — Fan a payroll run out to hundreds of payouts, each an idempotent transaction: retries can never double-pay. - exactly-once - **ATTRIBUTED FLOAT** — Track each employer's share of pooled float in real time, including the yield it earns while it waits. - yield attribution - **MULTI-RAIL PAYOUTS** — Pay out over chains, banks, and local partners through one schema: a new corridor is a connector, not a build. - one schema, every rail - **PAYROLL REPORTING** — Reconstruct any run (who was paid what, when, from which funding) at any timestamp, straight from the log. - full run traceability ## Metrics *BY THE NUMBERS* ## Payroll-grade, by design - **exactly-once** — every payout - **100%** — float attribution - **any** — payout rail - **real-time** — run visibility ## Code *NUMSCRIPT* ## A payout that cannot double-pay ### Idempotent by construction, not by best effort. Each payout in the run is its own Numscript transaction with a deterministic reference: replaying the batch skips what already executed instead of paying it again. ## FAQ **WHAT HAPPENS IF A BATCH FAILS HALFWAY?** Each payout is an idempotent transaction. Re-running the batch executes only what has not settled: no double pays, no manual diffing of who got paid. **CAN EMPLOYERS SEE THEIR FLOAT?** Yes. Pooled float is sub-ledgered per employer, so every employer's cash position, including the yield it earns, is exact and queryable in real time. **HOW DO CONTRACTOR AND EMPLOYEE FLOWS DIFFER?** Both are transaction patterns on the same ledger: different account trees, withholding logic, and reporting, with the same guarantees underneath. **WHICH PAYOUT RAILS ARE SUPPORTED?** Stablecoin transfers, bank rails, and local payout partners normalize into one schema through Connectivity; adding one is configuration, not code. ## Closing *GET STARTED* ## Run payroll you can replay safely See how Formance fits your payout flows: book a demo or start building. --- *Lite summary of [Crypto Payroll](https://www.formance.com/solutions/digital-assets/crypto-payroll). Request with `Accept: text/markdown` for this view.* --- title: Crypto Neobanks description: "Fiat sits with a banking partner, crypto with custodians, and the app stitches balances together from API calls. When providers disagree, users see wrong numbers, and safeguarding reviews turn into fire drills." canonical: "https://www.formance.com/solutions/digital-assets/crypto-neobank" type: solution-lite updated: "2026-07-28T15:59:38.961Z" --- *CRYPTO NEOBANKS* # Balances your users can trust, fiat and crypto side by side One ledger for every user balance across fiat, stablecoins, and crypto: surfaced in-app in real time, reconciled against custodians, ready for the regulator. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Your app shows a balance. Can you prove it? ### User balances derived from provider APIs are a liability. Fiat sits with a banking partner, crypto with custodians, and the app stitches balances together from API calls. When providers disagree, users see wrong numbers, and safeguarding reviews turn into fire drills. > Consumer platforms surface Formance balances in-app: the ledger is the product, not just the back office. - User balances are stitched from provider APIs instead of owned in one record. - Fiat and crypto live in separate systems that never quite agree. - Card spend, trades, and top-ups race each other, and balances drift. - Safeguarding and proof-of-funds requests require days of manual reconstruction. ## Flow of funds *FLOW OF FUNDS* ## Every user action, one balance ### Top-ups, trades, and spend post to the same multi-asset account. A top-up credits the user, a trade converts between assets atomically, and card spend debits with holds and captures, all against one account tree, reconciled continuously against banking partners and custodians. *real-time balances* - top-up: fiat in - user balance: multi-asset account - trade / spend: convert · card - providers: banks · custodians ## Capabilities *CAPABILITIES* ## The primitives consumer platforms need ### Built on the open-source Formance ledger. Multi-asset user accounts, real-time balance queries, and continuous provider reconciliation, composed for consumer scale. - **MULTI-ASSET ACCOUNTS** — Fiat, stablecoins, and crypto in one account tree per user, with per-asset precision and one aggregated position. - one user, one record - **REAL-TIME BALANCE API** — Surface ledger balances directly in-app: the number users see is the system of record, not a cached copy. - ledger-backed UX - **SPEND & TRADE FLOWS** — Card holds, captures, reversals, and asset conversions modeled as atomic transactions: no race conditions, no drift. - atomic conversions - **SAFEGUARDING REPORTS** — Reconstruct user funds against segregated accounts at any timestamp, straight from the immutable log. - point-in-time proof ## Metrics *BY THE NUMBERS* ## Consumer-grade, by design - **1** — balance per user - **real-time** — in-app balances - **1000s** — transactions per second - **100%** — safeguarding history ## Code *NUMSCRIPT* ## A trade is one atomic conversion ### Debit one asset, credit the other, capture the fee, together. A single Numscript transaction converts a user's fiat into crypto and captures the platform fee, with no intermediate state where the user holds neither. ## FAQ **CAN THE APP READ BALANCES FROM THE LEDGER DIRECTLY?** Yes. Balances are derived in real time from the transaction log and served over the API, so what users see is the system of record itself. **HOW DO FIAT AND CRYPTO COEXIST?** Every asset lives in the same double-entry model with its own precision. A user's position aggregates across assets in one query, with no cross-system joins. **WHAT ABOUT CARD AUTHORIZATIONS?** Holds, captures, reversals, and refunds are first-class transaction patterns, so spend flows post correctly even when settlement lags authorization. **HOW DOES SAFEGUARDING WORK?** User funds map to segregated account trees reconciled against banking partners and custodians continuously: safeguarding reports reproduce for any date. ## Closing *GET STARTED* ## Ship balances you can stand behind See how Formance fits your product: book a demo or start building. --- *Lite summary of [Crypto Neobanks](https://www.formance.com/solutions/digital-assets/crypto-neobank). Request with `Accept: text/markdown` for this view.* --- title: Crypto Payments description: "A cross-border payment crosses banks, ramps, and chains, each hop with its own rate, fee, and timing. Hard-coded logic breaks mid-corridor, funds sit in limbo, and no one can trace a cent end to end." canonical: "https://www.formance.com/solutions/digital-assets/crypto-payments" type: solution-lite updated: "2026-07-28T15:59:42.104Z" --- *CRYPTO PAYMENTS* # Move money through stablecoins without losing the trail Orchestrate fiat-to-stablecoin-to-fiat corridors as atomic multi-hop flows, with FX, fees, and gas accounted for end to end. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## The corridor is fast. The accounting is not. ### On-chain confirmation is not settlement. A cross-border payment crosses banks, ramps, and chains, each hop with its own rate, fee, and timing. Hard-coded logic breaks mid-corridor, funds sit in limbo, and no one can trace a cent end to end. > Payment companies run the stablecoin corridor on Formance, every hop posted to one auditable flow. - Multi-hop flows stall mid-corridor, leaving funds in limbo with no recorded state. - FX rates, ramp fees, and gas are hard-coded, so revenue capture breaks at scale. - On-chain confirmation gets booked as settlement when fiat has not actually landed. - Per-corridor compliance reporting means reconstructing flows across three systems. ## Flow of funds *FLOW OF FUNDS* ## Fiat in, stablecoin across, fiat out ### One flow, every hop accounted, end to end. Pay-in lands in local fiat, the on-ramp converts to stablecoin, the corridor moves value across chains, and the off-ramp pays out in destination currency. Each hop is a double-entry posting in the same traceable flow. *end-to-end traceability* - pay-in: local fiat collected - on-ramp: fiat → stablecoin - corridor: cross-chain transfer - payout: destination fiat ## Capabilities *CAPABILITIES* ## The primitives payment corridors need ### Built on the open-source Formance ledger. Multi-hop orchestration, declarative FX and fee capture, and ramp connectivity, composed for hybrid money movement. - **MULTI-HOP ORCHESTRATION** — Compose corridors as durable workflows: each hop atomic, a failed step reversing the flow safely instead of stranding funds. - atomic, reversible - **FX & FEE CAPTURE** — Conversion rates, spreads, ramp fees, and gas modeled declaratively per hop, so revenue is captured by construction. - declarative capture - **SETTLEMENT STATES** — Distinguish initiated, confirmed, and settled per rail, so books reflect where money actually is, not where a webhook said it was. - true settlement - **RAMP CONNECTIVITY** — Normalize banks, PSPs, on/off-ramps, and chains into one schema: adding a corridor partner is a connector, not a rewrite. - one schema, every rail ## Metrics *BY THE NUMBERS* ## Corridor-grade, by design - **100%** — hop traceability - **0** — funds in limbo - **any** — rail or chain - **real-time** — corridor visibility ## Code *NUMSCRIPT* ## A hop is a transaction, not a webhook ### Convert, capture the spread, and move on — atomically. A single Numscript transaction books the on-ramp conversion: fiat leaves the collection account, stablecoin enters the corridor float, and the FX spread is captured in the same operation. ## FAQ **WHAT HAPPENS WHEN A HOP FAILS?** Corridors run as durable workflows: each hop is atomic, and a failure reverses the completed legs safely instead of leaving funds stranded between systems. **HOW DO YOU HANDLE ON-CHAIN VS FIAT SETTLEMENT TIMING?** The ledger models settlement states per rail (initiated, confirmed, settled), so a chain confirmation never gets booked as landed fiat. **CAN I TRACE A PAYMENT END TO END?** Yes. Every hop posts to the same flow with shared metadata, so any payment reconstructs from pay-in to payout, for support, compliance, or the regulator. **HOW DO I ADD A NEW CORRIDOR?** Ramps, banks, and chains normalize into one schema. A new corridor partner is a connector configuration, and your flow logic stays untouched. ## Closing *GET STARTED* ## Corridors you can account for See how Formance fits your payment flows: book a demo or start building. --- *Lite summary of [Crypto Payments](https://www.formance.com/solutions/digital-assets/crypto-payments). Request with `Accept: text/markdown` for this view.* --- title: "Custody & Wallets" description: "Pooled wallets hold millions across chains and storage tiers with no clear record of whose funds are whose. Attribution lives in application code, sweeps go unrecorded, and regulators want proof you cannot produce." canonical: "https://www.formance.com/solutions/digital-assets/custody-wallets" type: solution-lite updated: "2026-07-28T15:59:45.608Z" --- *CUSTODY & WALLETS* # Run omnibus custody with per-user truth Virtualize omnibus wallets, attribute every satoshi and cent to its owner, and reconcile hot and cold storage in real time. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Omnibus accounts are black boxes ### Pooling funds saves gas. It also destroys attribution. Pooled wallets hold millions across chains and storage tiers with no clear record of whose funds are whose. Attribution lives in application code, sweeps go unrecorded, and regulators want proof you cannot produce. > Custodians virtualize omnibus accounts on Formance, tracking ownership off-chain while funds stay pooled. - Pooled wallets hold customer funds with no auditable per-user attribution. - Hot/cold sweeps and internal transfers happen outside any system of record. - Balances are tracked per chain and per provider, never as one position. - Proof-of-funds and travel-rule requests take days of manual reconstruction. ## Flow of funds *FLOW OF FUNDS* ## Pooled on-chain, attributed off-chain ### Deposits pool for efficiency; ownership stays exact in the ledger. Deposits land in omnibus wallets, the sub-ledger attributes every unit to its owner, and internal transfers move off-chain at zero gas. Withdrawals debit the exact owner: attribution is never approximate. *fund attribution* - deposit: user funds in - omnibus wallet: pooled on-chain - sub-ledger: per-user attribution - withdrawal: sweep + payout ## Capabilities *CAPABILITIES* ## The primitives custodians need ### Built on the open-source Formance ledger. Omnibus sub-ledgering, multi-chain aggregation, and continuous reconciliation, composed for custody at scale. - **OMNIBUS SUB-LEDGERING** — Per-user balances inside pooled wallets and bank accounts, derived from an immutable log and queryable at any timestamp. - per-user attribution - **MULTI-CHAIN TRACKING** — One position per user across chains, wallets, and storage tiers, aggregated in a single query. - one position, every chain - **INTERNAL TRANSFERS** — Move funds between users off-chain as ledger transactions: instant, atomic, and gas-free. - zero-gas transfers - **STORAGE RECONCILIATION** — Reconcile ledger state against hot wallets, cold storage, and custodial providers continuously, with drift alerts. - drift alerts ## Metrics *BY THE NUMBERS* ## Custody-grade, by design - **100%** — fund attribution - **any** — chain or provider - **0 gas** — internal transfers - **real-time** — storage reconciliation ## Code *NUMSCRIPT* ## Attribution is a transaction, not a lookup table ### Pool the deposit and attribute the owner in one atomic operation. A single Numscript transaction records the on-chain deposit into the omnibus wallet and attributes the exact amount to its owner in the sub-ledger. ## FAQ **HOW DO YOU TRACK OWNERSHIP IN POOLED WALLETS?** Every pooled wallet is sub-ledgered: each user's share is a derived balance in an immutable double-entry log, exact at any timestamp, not a row in application state. **DO INTERNAL TRANSFERS TOUCH THE CHAIN?** No. User-to-user moves are ledger transactions against the same pooled wallet: instant, atomic, and free of gas, while the on-chain position stays unchanged. **CAN I PROVE FUNDS FOR A REGULATOR?** Yes. Point-in-time reports reconstruct per-user holdings and total positions across chains and storage tiers, reproducibly, straight from the log. **WHAT ABOUT HOT/COLD SWEEPS?** Sweeps are recorded as transfers between storage accounts and reconciled against on-chain state continuously, so custody operations never escape the record. ## Closing *GET STARTED* ## Custody with proof built in See how Formance fits your custody architecture: book a demo or start building. --- *Lite summary of [Custody & Wallets](https://www.formance.com/solutions/digital-assets/custody-wallets). Request with `Accept: text/markdown` for this view.* --- title: Tokenization Platforms description: "Tokens represent real assets, but the cash, distributions and redemptions live off-chain. Keeping both sides reconciled is the hard part." canonical: "https://www.formance.com/solutions/digital-assets/tokenization" type: solution-lite updated: "2026-06-26T10:23:02.513Z" --- *TOKENIZATION* # Tokenize real-world assets on auditable rails Connect off-chain cash flows to on-chain tokens with a double-entry ledger that keeps issuance, distributions and redemptions provably in sync. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## On-chain tokens, off-chain truth ### The cash leg is where tokenization breaks. Tokens represent real assets, but the cash, distributions and redemptions live off-chain. Keeping both sides reconciled is the hard part. > Tokenization platforms on Formance keep the cash leg provably in sync with on-chain supply. - Subscriptions and redemptions reconcile manually against on-chain supply. - Income distributions to holders are scripted ad-hoc and hard to audit. - Off-chain custody balances drift from the tokenized representation. - Regulators expect a provable link between the asset and its token. ## Flow of funds *FLOW OF FUNDS* ## Subscribe, distribute, redeem ### The cash leg, mirrored to the token leg. Investor cash subscribes into a custody account, income distributes pro-rata, and redemptions return capital — each posting mirrored to token events. *cash ↔ token* - subscribe: cash → custody - custody: asset held - distribute: income → holders - redeem: return capital ## Capabilities *CAPABILITIES* ## The cash leg, handled ### On the open-source Formance ledger. Custody, distributions and redemptions, provably linked to the token. - **CUSTODY LEDGER** — Track the cash and assets backing each token in segregated, double-entry accounts with derived balances. - segregated custody - **DISTRIBUTIONS** — Model pro-rata income distributions to holders as deterministic, auditable Numscript transactions. - deterministic, pro-rata - **TOKEN SYNC** — Keep off-chain postings and on-chain token events in lockstep, so cash and supply always agree. - cash ↔ token in sync ## Metrics *BY THE NUMBERS* ## Provable from day one - **cash↔token** — always in sync - **pro-rata** — distributions - **100%** — auditable ## Code *NUMSCRIPT* ## Distribute income, pro-rata ### Split a distribution across holders in one transaction. Allocate an income distribution across token holders proportionally — deterministic and fully auditable. ## FAQ **HOW DO YOU LINK THE TOKEN TO THE ASSET?** The cash and assets backing each token live in segregated, double-entry custody accounts. Off-chain postings and on-chain token events are kept in lockstep, giving regulators a provable link between asset and token. **HOW ARE DISTRIBUTIONS HANDLED?** Pro-rata income distributions are deterministic Numscript transactions — auditable and reproducible. Allocations cannot silently drift from the holder register. **WHAT KEEPS CASH AND SUPPLY IN SYNC?** Subscriptions, distributions and redemptions each post on the cash leg and mirror to token events, so circulating supply and backing cash always agree. **IS THE FULL HISTORY AUDITABLE?** Yes. Every movement is an immutable double-entry transaction, so you can reconstruct custody balances and token state at any point in time. ## Closing *GET STARTED* --- *Lite summary of [Tokenization Platforms](https://www.formance.com/solutions/digital-assets/tokenization). Request with `Accept: text/markdown` for this view.* --- title: International Money Transfers description: "Each corridor adds another provider, FX step and settlement timeline. Without a single ledger, funds in flight are impossible to track and prove." canonical: "https://www.formance.com/solutions/corporate-treasury/international-payments" type: solution-lite updated: "2026-06-26T10:23:37.403Z" --- *MONEY TRANSFERS* # Move money across borders on a ledger you can prove Orchestrate multi-currency transfers across banks and PSPs, hold customer funds safely, and reconcile every payout automatically. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Cross-border flows are a reconciliation nightmare ### Many rails, many currencies, many failure modes. Each corridor adds another provider, FX step and settlement timeline. Without a single ledger, funds in flight are impossible to track and prove. > Payment teams on Formance safeguard funds and reconcile every corridor from a single ledger. - Funds in transit are scattered across provider accounts with no unified view. - FX conversions and fees are booked outside the ledger, breaking reconciliation. - Failed or delayed payouts leave customer balances in an ambiguous state. - Each new corridor means another bespoke integration and reconciliation job. ## Flow of funds *FLOW OF FUNDS* ## Collect, convert, pay out ### Every corridor is the same chain of postings. Collect from the sender, hold in a safeguarded account, convert across currencies, and pay out — each step an auditable transaction. *safeguarded funds* - collect: sender → hold - safeguard: held funds - fx: convert - payout: to beneficiary ## Capabilities *CAPABILITIES* ## Orchestration that reconciles itself ### On the open-source Formance ledger. Safeguarding, FX postings and multi-provider payouts, in one model. - **SAFEGUARDING** — Hold customer funds in clearly segregated accounts with balances derived from an immutable log. - segregated, derived balances - **FX & FEES** — Book conversions, spreads and fees as explicit postings so multi-currency flows stay reconciled. - multi-currency, reconciled - **PAYOUT ORCHESTRATION** — Drive retries, waits and exactly-once payouts across banks and PSPs with programmable flows. - exactly-once payouts ## Metrics *BY THE NUMBERS* ## Every corridor, accounted for - **multi-ccy** — currencies - **auto** — reconciliation - **exactly-once** — payouts ## Code *NUMSCRIPT* ## A transfer that books its own FX ### Collect, convert and pay out as one declarative flow. Move a sender deposit into a safeguarded account and post the FX spread to revenue in a single transaction. ## FAQ **HOW ARE CUSTOMER FUNDS SAFEGUARDED?** Funds are held in clearly segregated accounts with balances derived from an immutable log, so safeguarded money is always provable and never commingled with operating funds. **HOW IS FX KEPT RECONCILED?** Conversions, spreads and fees are booked as explicit postings inside the same flow. Multi-currency transfers stay reconciled because the FX leg lives on the ledger, not in a side system. **WHAT HAPPENS WHEN A PAYOUT FAILS?** Payouts run as programmable flows with retries and waits, and they are exactly-once. A failed or delayed payout never leaves a balance in an ambiguous state. **HOW HARD IS IT TO ADD A NEW CORRIDOR?** New banks and PSPs plug in through normalized connectors. Adding a corridor is a connector and configuration change, not another bespoke reconciliation job. ## Closing *GET STARTED* --- *Lite summary of [International Money Transfers](https://www.formance.com/solutions/corporate-treasury/international-payments). Request with `Accept: text/markdown` for this view.* --- title: Digital Asset Exchanges description: "Customer wallets, the matching engine and your banking and on-chain rails drift apart. Reconciling them under load is where exchanges lose money and trust." canonical: "https://www.formance.com/solutions/digital-assets/exchanges-trading" type: solution-lite updated: "2026-06-26T10:22:21.296Z" --- *DIGITAL ASSET EXCHANGES* # Run an exchange ledger that always balances Track customer balances, trades, fees and settlements across fiat and crypto rails on a single double-entry ledger — with the audit trail regulators expect. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Internal balances and rails disagree ### Custody, trading and settlement each keep their own books. Customer wallets, the matching engine and your banking and on-chain rails drift apart. Reconciling them under load is where exchanges lose money and trust. > Exchanges on Formance keep custody, trading and settlement on one ledger that always balances. - Customer balances are recomputed instead of derived from an immutable log. - Fees, rebates and spreads are booked inconsistently across products. - Fiat and crypto settlements reconcile on different schedules and systems. - Proving solvency to an auditor means stitching together exports by hand. ## Flow of funds *FLOW OF FUNDS* ## From deposit to settled trade ### Every leg of a trade is a posting on the same ledger. Deposits credit a customer wallet, a matched trade moves balances between accounts, fees route to revenue, and withdrawals settle back out — all double-entry. *always balanced* - deposit: rail → wallet - trade: match & post - fees: to revenue - withdraw: wallet → rail ## Capabilities *CAPABILITIES* ## Built for exchange-grade money movement ### On the open-source Formance ledger. Custody balances, trade postings and multi-rail settlement, unified. - **CUSTOMER WALLETS** — Per-customer, per-asset balances derived from an immutable double-entry log — never overwritten, always reconstructable. - derived, never overwritten - **TRADE POSTINGS** — Express every fill, fee and rebate as a deterministic Numscript transaction so books balance by construction. - balanced by construction - **MULTI-RAIL SETTLEMENT** — Normalize fiat PSPs, banks and on-chain rails into one settlement model and keep internal orders in sync with provider refs. - fiat + crypto, one model ## Metrics *BY THE NUMBERS* ## Consistency under load - **0** — balance drift - **real-time** — solvency view - **multi-asset** — fiat + crypto ## Code *NUMSCRIPT* ## A trade that cannot unbalance the books ### Move balances and route the fee in one atomic posting. Settle a matched trade between two customers and route the fee to revenue — atomic and idempotent. ## FAQ **HOW DO BALANCES STAY CORRECT UNDER LOAD?** Customer balances are derived from an immutable double-entry log rather than recomputed in place. Concurrent fills, fees and settlements post as transactions, so the books cannot drift even at peak throughput. **CAN I SHOW SOLVENCY IN REAL TIME?** Yes. Because every wallet balance is reconstructable from the log, you can produce a point-in-time solvency view across fiat and crypto without stitching exports together by hand. **HOW ARE FEES AND REBATES HANDLED?** Every fill, fee and rebate is an explicit posting in the same transaction. There is no separate fee system to reconcile — revenue is booked as the trade settles. **DO YOU SUPPORT FIAT AND CRYPTO RAILS?** Fiat PSPs, banks and on-chain rails normalize into one settlement model, and internal orders stay linked to provider references so reconciliation is automatic. ## Closing *GET STARTED* --- *Lite summary of [Digital Asset Exchanges](https://www.formance.com/solutions/digital-assets/exchanges-trading). Request with `Accept: text/markdown` for this view.* --- title: Stablecoin Issuers description: "Off-chain reserves, mint/burn events and bank balances live in disconnected systems. Reconciling them is manual, error-prone, and impossible to prove after the fact." canonical: "https://www.formance.com/solutions/digital-assets/stablecoin-issuance" type: solution-lite updated: "2026-06-26T10:21:41.245Z" --- *STABLECOIN ISSUERS* # Issue stablecoins on a ledger that proves its reserves Back every token 1:1 with segregated fiat, mint and redeem programmatically, and produce an immutable audit trail your auditors and regulators can trust. > _TRUSTED BY TEAMS MOVING MONEY/ ## Problem *THE PROBLEM* ## Spreadsheets cannot back a token ### Reserve integrity is an accounting problem, not a smart-contract one. Off-chain reserves, mint/burn events and bank balances live in disconnected systems. Reconciling them is manual, error-prone, and impossible to prove after the fact. > Stables runs its reserve ledger on Formance — every token traceable to a segregated dollar. - Reserve balances drift from circulating supply with no single source of truth. - Mint and redeem flows are scripted ad-hoc, with no idempotency or replay safety. - Auditors ask for point-in-time reserve proofs your stack cannot reconstruct. - Every new banking partner or rail means another bespoke integration. ## Flow of funds *FLOW OF FUNDS* ## Every token traces back to a dollar ### Fiat in, token out — one auditable chain of double-entry transactions. Deposits land in a segregated reserve, minting is posted against that reserve, and redemptions reverse the exact path. Balances are derived, never overwritten. *proof of reserves* - fiat deposit: bank → reserve - reserve: segregated 1:1 - mint: token issued - redeem: burn → payout ## Capabilities *CAPABILITIES* ## The primitives issuers need ### Built on the open-source Formance ledger. A double-entry core, programmable money movement and normalized connectivity — composed for reserve-backed issuance. - **RESERVE LEDGER** — A double-entry account tree segregating fiat reserves per currency and per banking partner, with derived balances you can query at any timestamp. - point-in-time balances - **MINT / REDEEM** — Model issuance and redemption as deterministic Numscript transactions — idempotent, exactly-once, and reversible by construction. - exactly-once - **PROOF OF RESERVES** — Reconstruct circulating supply and backing reserves for any point in time, straight from the immutable transaction log. - immutable log - **BANKING CONNECTIVITY** — Normalize deposits and payouts from every bank and PSP into one schema, so adding a reserve partner never changes your logic. - one schema, every rail ## Metrics *BY THE NUMBERS* ## Reserve-grade, by design - **1:1** — reserve backing - **100%** — auditable history - **exactly-once** — mint & redeem - **days** — time to integrate ## Code *NUMSCRIPT* ## Minting is a transaction, not a script ### Back every token with a deposit in the same atomic operation. A single Numscript transaction moves fiat into the segregated reserve and issues the equivalent token to the holder — atomic, idempotent and auditable. ## FAQ **HOW IS 1:1 BACKING ENFORCED?** Every mint is posted against a matching fiat deposit in a segregated reserve account. Circulating supply and reserves are derived from the same immutable log, so backing is verifiable at any timestamp — not asserted after the fact. **CAN I PRODUCE PROOF OF RESERVES?** Yes. Reconstruct circulating supply and backing reserves for any point in time straight from the transaction log, and hand auditors a reproducible figure instead of a spreadsheet snapshot. **ARE MINT/REDEEM FLOWS SAFE TO RETRY?** Issuance and redemption are deterministic Numscript transactions — idempotent and exactly-once. A retried or replayed request can never double-mint or double-burn. **WHAT ABOUT MULTIPLE BANKING PARTNERS?** Deposits and payouts from every bank and PSP normalize into one schema. Adding a reserve partner is a connector change, not a rewrite of your issuance logic. ## Closing *GET STARTED* --- *Lite summary of [Stablecoin Issuers](https://www.formance.com/solutions/digital-assets/stablecoin-issuance). Request with `Accept: text/markdown` for this view.* --- # Blog Full text of each entry is served at its URL with `Accept: text/markdown`. - [Cloud-Based Core Banking: Build vs Buy for the Ledger Layer](https://www.formance.com/blog/product/cloud-based-core-banking-build-vs-buy-ledger): The ledger is the hardest part of cloud-based core banking to get right. Here's a build vs buy guide on the four mechanisms, key signals, and a full comparison. - [Understanding Transaction Finality](https://www.formance.com/blog/financial-operations/understanding-transaction-finality-refresh): Learn how transaction finality works across ACH, cards, wires, and blockchain rails, and how to design a ledger that knows when a payment is truly final. - [Three-Way Matching in Accounts Payable Explained](https://www.formance.com/blog/financial-operations/three-way-matching-in-accounts-payable): Learn how three-way matching in accounts payable prevents payment errors by posting match results through a clearing account in a programmable ledger. - [AI Agent Spending Limits (That Actually Hold)](https://www.formance.com/blog/industry-analysis/ai-agent-spending-limits): Stop concurrent overspend with ledger-enforced AI agent spending limits. Learn atomic reservations, nested budgets, and retry-safe controls that hold at machine speed. - [Build vs Buy a Ledger: Engineering Decision Framework ](https://www.formance.com/blog/competitive/build-vs-buy-a-ledger-engineering): A build vs buy a ledger framework with five pass/fail checks covering write-time correctness, regulatory rules, rails expansion, engineer capacity, and exit cost. - [Defining Double-Entry](https://www.formance.com/blog/financial-operations/defining-double-entry): Learn what double-entry means, how accounts, transactions, and entries balance, and what production ledgers need to prevent reconciliation drift. - [What Is a Payment Orchestration Layer? Architecture and Build Tips](https://www.formance.com/blog/financial-operations/payment-orchestration-layer-architecture): Learn how a payment orchestration layer routes payments, improves authorization rates, and why it needs a ledger foundation. - [Formance vs. TigerBeetle vs. Fragment: Choosing a Core Ledger](https://www.formance.com/blog/competitive/formance-vs-tigerbeetle-vs-fragment): Compare Formance vs. TigerBeetle vs. Fragment on programmability, deployment, reconciliation, multi-asset support, throughput, and auditability. - [How to Build Recurring Crypto Payments (Subscriptions On-Chain)](https://www.formance.com/blog/product/recurring-crypto-payments-subscriptions-on-chain): Build recurring crypto payments with scoped authorization, idempotent renewals, reconciliation, and reliable on-chain settlement. - [Token Accounting: How AI Companies Should Track Cost and Margin per Token ](https://www.formance.com/blog/financial-operations/token-accounting-ai-margin): Token accounting helps AI companies track revenue, serving cost, prepaid drawdown, and gross margin per token. - [AP2, x402, and ACP Explained: The Agentic Payment Protocols Compared](https://www.formance.com/blog/product/ap2-x402-acp-agentic-payment-protocols): AP2, x402, and ACP occupy different layers of the agentic payment stack. Compare their authorization models, rails, maturity, and what each leaves on your ledger. - [Formance vs Modern Treasury in 2026: Plans, Costs & How It Compares](https://www.formance.com/blog/competitive/formance-vs-modern-treasury): Compare Formance and Modern Treasury in 2026: plans, pricing, features, and how each fits as the core ledger beneath your payment operations. - [Self-Custody Wallets Explained: How They Work and Trade-offs](https://www.formance.com/blog/product/self-custody-wallets-explained): Learn how self-custody wallets work, compare signing designs, and model withdrawals, reconciliation, ledger boundaries, and compliance. - [Real-Time Payments vs ACH: Speed, Cost, and When to Use Each](https://www.formance.com/blog/financial-operations/real-time-payments-vs-ach): Compare Real-Time Payments and ACH on speed, cost, and use cases. Learn how ledger design must differ for each rail to avoid reconciliation drift. - [Immutable Ledgers Explained: How Append-Only Data Models Work](https://www.formance.com/blog/financial-operations/immutable-ledgers-append-only-data-models): Learn how immutable ledgers use append-only writes, hash chaining, and compensating postings to preserve financial history. - [Core Banking System Architecture: A Reference Model For Modern Stacks](https://www.formance.com/blog/financial-operations/core-banking-system-architecture): A core banking system architecture model separating ledger, money movement, compliance, and APIs to reduce reconciliation drift. - [How Automated Payment Reconciliation Works (And Why Manual Breaks)](https://www.formance.com/blog/embedded-finance/automated-payment-reconciliation): Manual reconciliation breaks across payment rails. Learn how an automated payment reconciliation catches drift before it becomes a customer-funds crisis. - [Formance vs Fragment: Built for What Comes After the MVP](https://www.formance.com/blog/competitive/formance-vs-fragment): Compare Formance vs Fragment for post-MVP ledger scale across programmable logic, multi-asset support, reconciliation, deployment, and auditability. - [Programmable Payments: How Money Logic Moves Into the Ledger](https://www.formance.com/blog/product/programmable-payments-ledger-logic): Learn how programmable payments enforce money movement rules at commit time, preventing duplicate postings and reconciliation drift in your ledger. - [The Six Steps of the Payment Reconciliation Process](https://www.formance.com/blog/product/six-steps-payment-reconciliation): Learn the 6-step payment reconciliation process: rail data collection, ledger extraction, matching, exception handling, adjustments, and period close. - [Payment Orchestration vs. Payment Gateway: Which Does Your Stack Need?](https://www.formance.com/blog/industry-analysis/payment-orchestration-vs-payment-gateway): Payment orchestration vs payment gateway: compare gateways, orchestration, and ledgers as routing and reconciliation complexity grows. - [Asset Tokenization Explained: RWAs, Custody, Tokens, and Ledgers](https://www.formance.com/blog/industry-analysis/asset-tokenization-explained): Learn how asset tokenization connects real-world assets, custody records, on-chain tokens, and core ledgers, and why reconciliation is the control point. - [What is the Formance MCP server? ](https://www.formance.com/blog/changelog/formance-mcp-server): Learn how the Formance Model Context Protocol (MCP) server lets AI agents inspect ledger, payments, and reconciliation data while preserving a read-only boundary. - [What is Payment Orchestration? A Technical Primer](https://www.formance.com/blog/financial-operations/what-is-payment-orchestration): Learn how payment orchestration routes transactions across PSPs, where failover breaks, and why reconciliation needs double-entry records. - [What Are Agentic Payments? The Complete Guide](https://www.formance.com/blog/product/what-are-agentic-payments): Agentic payments let AI agents execute transactions under pre-approved mandates. Learn the models, failure points, and required ledger infrastructure. - [Payment reconciliation process: a complete guide](https://www.formance.com/blog/financial-operations/payment-reconciliation-process): Learn the payment reconciliation process, common failure modes, and ledger architecture that engineering and finance teams need to automate reliable reconciliation. - [Introducing Formance Studio](https://www.formance.com/blog/product/introducing-formance-studio): Formance Studio turns a plain-English description into a validated ledger schema: accounts, transaction logic, and queries, tested against a live ledger. - [Event sourcing vs event-driven architecture: what's the difference?](https://www.formance.com/blog/financial-operations/event-sourcing-vs-event-driven-architecture): Event sourcing stores state as immutable facts. Event-driven architecture routes messages between services. Learn how financial systems need both. - [Autonomous finance: what it means for payment infrastructure](https://www.formance.com/blog/financial-operations/autonomous-finance): Learn how autonomous finance payment infrastructure enforces immutable postings, idempotent contracts, and traceable flows of funds. - [Formance vs TigerBeetle](https://www.formance.com/blog/competitive/formance-vs-tigerbeetle): Compare Formance and TigerBeetle by stack layer: full-stack operational ledger platform versus high-throughput financial transaction storage engine. - [What is a Ledger Database?](https://www.formance.com/blog/product/what-is-a-ledger-database): Learn what a ledger database is, how it protects balances, and when teams need one for reconciliation and auditability. - [Reconciliation in Finance: From Spreadsheets to Programmable Policies](https://www.formance.com/blog/financial-operations/reconciliation-in-finance): How reconciliation in finance moves from spreadsheets to programmable ledger policies for matching, drift detection, and audit readiness. - [Tokenization of Money: A Builder's Reference](https://www.formance.com/blog/product/tokenization-of-money-infrastructure): A technical reference to tokenization of money for builders designing off-chain reconciliation, ledger controls, and compliance-ready stablecoin systems. - [How to ledger stablecoin flows on a regulated core banking system](https://www.formance.com/blog/financial-operations/stablecoin-ledger-core-banking-system): Learn how a programmable ledger keeps stablecoin flows reconciled across core banking, reserves, redemptions, and regulatory reporting. - [Non-Custodial vs. Custodial Wallets](https://www.formance.com/blog/financial-operations/non-custodial-vs-custodial-wallets): Compare non-custodial and custodial wallets across key control, MPC, regulatory risk under MiCA and GENIUS, reconciliation, and off-chain ledger design. - [Transaction Reconciliation at Scale: An Engineering Guide](https://www.formance.com/blog/engineering/transaction-reconciliation-at-scale-for-eng): Learn transaction reconciliation architecture for ledger invariants, provider normalization, matching, and exception handling as transaction volume grows. - [Reconciling On-Chain and Off-Chain Transactions at Scale](https://www.formance.com/blog/product/on-chain-off-chain-reconciliation-at-scale): Learn where on-chain/off-chain reconciliation breaks across confirmations, internal transfers, cross-chain drift, and audit-ready controls. - [Cross-border Payments: A Technical Implementation Guide](https://www.formance.com/blog/embedded-finance/cross-border-payments-guide): Design cross-border payments with a core ledger, rail orchestration, FX controls, reconciliation, and compliance checkpoints at every hop - [Three-way Matching for Fintech Engineering Teams](https://www.formance.com/blog/engineering/three-way-matching-fintech): Learn how fintech engineering teams use three-way matching across ledgers, PSP reports, and bank statements for daily reconciliation. - [What is Bank Reconciliation?](https://www.formance.com/blog/embedded-finance/what-is-bank-reconciliation): Learn how bank reconciliation works from an engineering angle: matching rules, ledger design, exception handling, and automation for payment infrastructure. - [Intercompany Reconciliation Explainer](https://www.formance.com/blog/embedded-finance/intercompany-reconciliation-explainer-fintechs): Learn how multi-entity fintechs can match, eliminate, and automate intercompany entries to prevent phantom profit and close the books cleanly. - [Payment rails explained for fintech engineers](https://www.formance.com/blog/financial-operations/payment-rails-explained-for-fintech-engineers): Payment rails explained for fintech engineers: compare bank transfers, cards, wires, RTP, FedNow, digital assets, and stablecoins by speed, cost, risk, and settlement. - [A technical guide on programmable finance](https://www.formance.com/blog/financial-operations/programmable-finance-technical-guide): Learn how programmable finance uses ledgers, rules, connectivity, and reconciliation to track and move funds with traceability. - [General Ledger Definition for Software Teams](https://www.formance.com/blog/financial-operations/general-ledger-software-teams): Learn what a general ledger is, which components your code must populate correctly, and how clean product ledger design prevents reconciliation failures. - [How to Automate Reconciliation Across Multi-Rail Money Movement](https://www.formance.com/blog/financial-operations/automate-reconciliation): Learn how to automate reconciliation across multiple payment rails with normalized data, matching rules, and a ledger that stays accurate at scale. - [An Architectural Primer on Embedded Finance ](https://www.formance.com/blog/embedded-finance/embedded-finance-architecture-primer): Learn embedded finance architecture patterns for ledgers, provider integrations, orchestration, and reconciliation before products scale. - [An Engineering Buying Framework for a Payment Processor](https://www.formance.com/blog/industry-analysis/an-engineering-buying-framework-for-a-payment-processor): An engineering framework for evaluating payment processors on idempotency, failover, ledger, reconciliation, and compliance. - [What Engineers Need to Know About Real-Time Payments and FedNow](https://www.formance.com/blog/financial-operations/what-engineers-need-to-know-about-real-time-payments-and-fednow): FedNow makes settlement instant and irrevocable. Learn how to handle retry logic, ledger design, reconciliation, and fraud controls on real-time rails. - [Double-Entry Accounting for Engineers Building Financial Products](https://www.formance.com/blog/engineering/double-entry-accounting-for-engineers-building-financial-products): Learn how double-entry accounting prevents balance drift, fee gaps, and reconciliation failures in payment systems—with worked examples and a practical checklist. - [How to Know When You Need Ledger as a Service](https://www.formance.com/blog/financial-operations/how-to-know-when-you-need-ledger-as-a-service): Learn what Ledger as a Service is, where it fits in your stack, its capabilities, and when you need one. - [Programmable Wallets: Architecture, Holds, and the Ledger Layer](https://www.formance.com/blog/product/programmable-wallets-architecture-holds-and-the-ledger-layer): Learn how programmable wallet architecture layers, including policy, orchestration, and ledger, keep balance logic consistent as your fintech product scales. - [Why Modern Fintechs Layer a Ledger Under Their Core Banking System](https://www.formance.com/blog/industry-analysis/why-modern-fintechs-layer-a-ledger-under-their-core-banking-system): Core banking and modern ledgers solve different problems. Learn the architectural split, why fintechs need both, and how to decide what to build or buy. - [Account Reconciliation Patterns for High-Volume Fintech](https://www.formance.com/blog/financial-operations/account-reconciliation-patterns-for-high-volume-fintech): Learn how high-volume fintech teams build reconciliation systems that auto-match transactions, detect breaks in minutes, and satisfy regulators without manual work. - [How to Develop a Crypto Payment Gateway for Multi-Rail Payments](https://www.formance.com/blog/engineering/how-to-develop-a-crypto-payment-gateway-for-multi-rail-payments): Learn how to architect a multi-rail crypto payment gateway that handles USDC, USDT, fiat settlement, and new rails without breaking existing flows. - [The Different Types of Stablecoins](https://www.formance.com/blog/industry-analysis/the-different-types-of-stablecoins): Learn how fiat-backed, crypto-backed, commodity-backed, and algorithmic stablecoins work and which peg model fits payment infrastructure. - [Money Movement Architecture for Multi-Rail Fintechs](https://www.formance.com/blog/engineering/money-movement-architecture-for-multi-rail-fintechs): A practical guide to money movement architecture for fintechs running multiple payment rails. Learn how a ledger-first design absorbs new rails without compounding technical debt. - [Agentic Payments: How AI Agents Move Money](https://www.formance.com/blog/product/how-aI-agents-move-money): AI agents retry at machine speed, spawn sub-agents, and execute across rails. Here's the infrastructure you need to handle it without duplicate charges. - [How to Invest in Stablecoins for Money Movement](https://www.formance.com/blog/financial-operations/how-to-invest-in-stablecoins-for-money-movement): Learn how businesses invest in stablecoins for cross-border payments, treasury ops, and money movement with this ledger and compliance guide. - [What Is BaaS? Banking-as-a-Service for Engineering Teams](https://www.formance.com/blog/industry-analysis/what-is-baas): Banking‑as‑a‑Service (BaaS) gives engineering teams access to regulated banking rails via APIs. Learn how the BaaS model works, how it differs from embedded finance/open banking, and what infrastructure you still need to build (ledger, reconciliation, idempotency, state management). - [Stablecoin Payments Architecture for Regulated Fintechs](https://www.formance.com/blog/industry-analysis/stablecoin-payments-architecture-for-regulated-fintechs): Learn how regulated fintechs should architect stablecoin payments, including on-ramp, off-ramp, and reconciliation infrastructure. - [Ledger Balance Explained for Product and Engineering Teams](https://www.formance.com/blog/financial-operations/understanding-ledger-balance-and-why-it-matters-in-fintech): Learn what ledger balance means, how it differs from available and pending balances, and how to design audit-grade ledger architecture for real-time authorization, reconciliation, and disputes. - [What Is a Subledger and When Do You Need One?](https://www.formance.com/blog/financial-operations/what-is-a-subledger): A subledger captures transaction-level postings behind your general ledger—enabling per-user balances, dispute resolution, and audit-grade traceability in fintech. - [What Is a Ledger? A Guide for Software Engineers](https://www.formance.com/blog/financial-operations/what-is-a-ledger): Learn what a ledger is, how it records money movement, and why double-entry, derived balances, and more matter in payment systems. - [What Is Programmable Money? A Practical Definition for Builders](https://www.formance.com/blog/engineering/what-is-programmable-money): Learn how programmable money works at the infrastructure layer and what it means for engineers building payment systems with atomic, ledger-enforced logic. - [New Connectivity with Fireblocks](https://www.formance.com/blog/product/fireblocks): Sync Fireblocks vault accounts, balances, and transactions into Formance Ledger to reconcile self-custodied digital assets and fiat in one system. - [New Connectivity with Coinbase Prime](https://www.formance.com/blog/product/coinbase-prime): Sync Coinbase Prime wallets, balances, and transactions into Formance Ledger to reconcile crypto and fiat in one system. - [On-Chain Confirmation Is Not Settlement](https://www.formance.com/blog/financial-operations/on-chain-confirmation-is-not-settlement): Stablecoin finality unfolds across blockchain, issuer, and fiat layers, each with its own rules. On-chain confirmation isn’t true settlement, and available balance means something different on every rail. - [New Connectivity with Tink](https://www.formance.com/blog/product/tink): New integration connects to banks across the UK and Europe, syncing transactions for real-time visibility and automated reconciliation. - [New Connectivity with Powens](https://www.formance.com/blog/product/powens): New integration connects to 2,000+ European banks, syncing transactions for real-time visibility and automated reconciliation. - [Transparency Is a Feature](https://www.formance.com/blog/engineering/why-formance-is-open-source): Why Formance is open source: transparency, auditability, business continuity, and self-hosting that reduce risk in financial infrastructure. - [Build or Buy a Core Ledger](https://www.formance.com/blog/engineering/build-or-buy-a-core-ledger): Building a ledger looks like an engineering problem. It's also an accounting problem, a compliance problem, and a long-term maintenance commitment. - [The Stablecoin Sandwich](https://www.formance.com/blog/financial-operations/the-stablecoin-sandwich): Carlos sent $500 to his mother Rosa in Guadalajara twenty minutes ago. It should be there by now. But his remittance company can’t tell you if it is, because the payment touched four different systems on the way, and none of them talk to each other. - [That Time a $400 Giveaway Became an $8M mistake](https://www.formance.com/blog/industry-analysis/that-time-a-400-giveaway-became-an-8m-mistake): A Bithumb input error created $40B in phantom Bitcoin. What it reveals about internal ledgers—and the risk every centralized exchange shares. - [Why Cross-Team Friction Persists in Financial Systems](https://www.formance.com/blog/financial-operations/why-cross-team-friction-persists-in-financial-systems): Cross-team friction in financial systems is more than a communication problem. Learn how explicit money flows, ledger clarity, and auditability reduce friction. - [When the Travel Rule Meets Stablecoins](https://www.formance.com/blog/financial-operations/when-the-travel-rule-meets-stablecoins): If you work with cross-border payments, you need to be acquainted with the Travel Rule and prepare for stablecoin compliance. - [The Travel Rule](https://www.formance.com/blog/financial-operations/the-travel-rule): Learn what the travel rule requires, when it applies to payouts and transfers, and how strong data architecture helps teams meet global compliance expectations. - [The Fiat-to-Digital Asset Playbook](https://www.formance.com/blog/financial-operations/the-fiat-to-digital-asset-playbook): Fiat ramps break when funds split across banking rails and blockchains. Learn how to design a Core Ledger that keeps your off-chain cash and on-chain assets in sync. - [The CeDeFi Ledger Playbook](https://www.formance.com/blog/financial-operations/the-cedefi-ledger-playbook): CeDeFi breaks standard ledgers because digital asset balances can change without transactions. Learn how to design a Core Ledger to shadow-ledger on-chain protocols. - [Preparing for MiCA](https://www.formance.com/blog/financial-operations/mica-implementation): MiCA’s transition period is entering its final months in many EU countries. Find out what this means for CASPs and stablecoin issuers that aren’t licensed yet. - [How Not to Build a Ledger](https://www.formance.com/blog/engineering/how-not-to-build-a-ledger-2): Race conditions and throughput cliffs are the hidden dragons of fintech systems. Learn how to design ledgers that stay both correct and fast. - [Why Formance Became DORA Compliant](https://www.formance.com/blog/company/why-formance-became-dora-compliant): Discover why Formance pursued DORA compliance early, what the process required, and how it strengthened operational resilience and trust for every customer. - [Ensuring Ledger Integrity](https://www.formance.com/blog/financial-operations/ensuring-ledger-integrity): Discover the six ledger invariants every NBFI must enforce to stay audit-ready. Ensure balances are reproducible, ownership traceable, and transparent. - [Introducing Assets Coloring](https://www.formance.com/blog/changelog/introducing-assets-coloring): Introducing assets coloring support in Numscript to tackle one of the hardest, fundamental core ledgering problems: Hidden funds lineage. - [Understanding Transaction Finality](https://www.formance.com/blog/financial-operations/understanding-transaction-finality): Learn how crypto and instant payments are reshaping how finance defines transaction finality and what “final” means in practice today. - [The Hidden Timeline of a Card Transaction](https://www.formance.com/blog/financial-operations/card-timeline-2): Card payments aren’t instant; there can be “gaps”. Bi-temporality should be a feature of your ledger for the sake of clarity, compliance, and control. - [What is Numscript and Why is it Awesome?](https://www.formance.com/blog/engineering/numscript): Discover Numscript, Formance’s declarative DSL for programmable ledgers—express intent once, execute atomically, and keep transactions auditable and traceable. - [The Color of Money](https://www.formance.com/blog/talks/fintech_devcon-2025-recording): Watch Clément Salaün’s Fintech_Devcon talk on “the color of money,” a ledgering concept that helps fintechs track fund origins, risk, and movement across banks. - [The Hidden Timeline of a Card Transaction](https://www.formance.com/blog/financial-operations/card-timeline-1): Card transactions are not instantaneous, but pass through several players in what is called the “Four Corner” model. Here’s why that matters. - [Trust is a Feature, Not a Feeling](https://www.formance.com/blog/financial-operations/300-trillion-minting-error): The recent $300 trillion PYUSD minting error shows why stablecoin stability depends on engineered governance: Controls that verify trust at code speed. - [Anticipating the Clarity Act](https://www.formance.com/blog/financial-operations/clarity-act): The Clarity Act could reshape digital asset rules in the U.S. Learn what’s proposed, what might happen, and how your organization should prepare now. - [Regulating Digital Resilience in the EU](https://www.formance.com/blog/financial-operations/dora-compliance): What DORA compliance means for fintechs, NBFIs and marketplaces as digital resilience requirements and vendor oversight reshape the financial ecosystem. - [Anne-Sybille Pradelles on Scaling Open-Source Financial Infrastructure](https://www.formance.com/blog/talks/podcast-how-they-build): Formance CEO Anne-Sybille Pradelles joins Lago CEO Anh-Tho Chuong on the “How They Build” podcast to discuss scaling open-source fintech infrastructure, breaking into the US market, and turning early customers into growth partners. - [Announcing Formance Ledger V2.3](https://www.formance.com/blog/changelog/ledger-v2.3): Formance Ledger V2.3 introduces a new ways to improve the performance of your installation, as well as a bundle of requested improvements. - [You May Already be an NBFI. Here's Why that Matters.](https://www.formance.com/blog/financial-operations/nbfi-alignment): Discover why being an NBFI changes everything, from compliance to product design, and how to align legal, product, and finance teams to meet regulatory demands. - [Breaking Down Stablecoin Regulations Under the GENIUS Act and MiCA](https://www.formance.com/blog/financial-operations/stablecoin-regulation): Find out what regulations apply to NBFIs issuing stablecoins under the GENIUS Act in the United States and MiCA in the EU. - [Euro-Ingenuity vs. Dollar-Genius ](https://www.formance.com/blog/financial-operations/stablecoins-emoney): Compare EU e‑money and US payment stablecoins (GENIUS Act): how they work, how they’re regulated, and why issuers need an independent ledger for compliance. - [Don Goodman: A Cognitive Theory of Community](https://www.formance.com/blog/talks/devopsdays-ams-2025): Learn how basic neuroscience and oxytocin dynamics can help build healthier technical communities—highlights from Don Goodman’s DevOpsDays Amsterdam talk. - [Defining Double Entry](https://www.formance.com/blog/engineering/defining-double-entry): A clear, formal definition of double-entry ledgers—what they are (and aren’t), why they matter, and how to model accounts, debits, and credits correctly. - [Clément Salaün: The Color of Money](https://www.formance.com/blog/talks/fintech_devcon-2025): Preview Clément Salaün’s fintech_devcon talk on the Color of Money—rethinking fungibility to model assets, liabilities, location, and risk in modern ledgers. - [Designing Commission Models](https://www.formance.com/blog/financial-operations/commission-models): Commission models hide complex tradeoffs. Learn how to structure and calculate commissions (fixed, %, step) to balance liquidity, retention, and revenue. - [Customer Story: Liberis](https://www.formance.com/blog/customer-story/liberis): How Liberis used Formance Ledger + Reconciliation to scale across 14 countries with zero reconciliation errors, faster launches, and a 2.5‑month go‑live. - [Structuring Invoices](https://www.formance.com/blog/marketplaces/structuring-invoices): Three invoicing models for marketplaces and platforms—customer commission, seller commission, and merchant-of-record—with the risks, benefits, and compliance impacts. - [How Not to Build a Ledger](https://www.formance.com/blog/engineering/how-not-to-build-a-ledger): Learn the most common ledger design anti-patterns (zero-entry, single-entry pitfalls) and the accounting principles engineers need to build auditable, drift-resistant systems. - [Announcing Formance $21M Series A Funding Round](https://www.formance.com/blog/company/formance-secures-21-million-dollar-in-series-a-funding-co-led-by-paypal-ventures-and-portage-ventures-to-expand-its-open-source-financial-infrastructure): Formance announces a $21M Series A co-led by PayPal Ventures and Portage Ventures to expand its open-source programmable ledger and platform. - [The Color of Money](https://www.formance.com/blog/engineering/color-of-money): Why classical fungibility breaks in fintech—and how the “Color of Money” helps trace funds, link assets to liabilities, and model location and risk in ledgers. - [Funds Traceability in Digital Ledgers](https://www.formance.com/blog/engineering/funds-traceability-in-digital-ledgers): See why classical double-entry can’t trace specific funds—and how alternative models improve asset‑liability mapping, backtracing, and auditability in fintech. - [Warehousing Promises](https://www.formance.com/blog/engineering/warehousing-promises): Why fintechs shouldn’t issue promises—they should warehouse them. Learn how promise warehousing improves traceability, auditability, and customer protection post‑Synapse. - [Debits and Credits](https://www.formance.com/blog/engineering/debits-and-credits-for-the-befuddled): Debits and credits are confusing because they’re contextual. Learn the asset/liability semantics of double-entry—and how a source/destination model simplifies ledger design. - [Ledgering, All the Way Up](https://www.formance.com/blog/engineering/ledgering-all-the-way-up): A practical guide to ledger types—general ledger, core ledger, cash ledger, and sub-ledgers—so you can choose the right system of record for your product. - [Announcing Formance Connectivity](https://www.formance.com/blog/product/announcing-formance-connectivity): Meet Formance Connectivity: a unified connector layer for payments and financial providers, with a normalized data model, transfer initiations, and temporal balance queries. - [Execution of Temporal Queries on Third-Party Data](https://www.formance.com/blog/engineering/execution-of-temporal-queries-on-third-party-data): How to run point-in-time (temporal) queries on providers that don’t support history natively—using observation, mutation logs, and an internal replicated data layer. - [Announcing Ledger V2](https://www.formance.com/blog/product/announcing-formance-ledger-v2): Formance Ledger v2 introduces bi-temporality for time-travel queries, better audits, and clean corrections—plus improved filtering and storage isolation via buckets. - [Announcing Formance Platform](https://www.formance.com/blog/product/announcing-formance-platform): Introducing the Formance Platform: a modular financial core combining Ledger, Connectivity, Flows, and Reconciliation—built for ownership, control, and enterprise-grade ops. - [How Getmomo Banking Platform Streamlines Its Rental Operations with Formance](https://www.formance.com/blog/customer-story/getmomo): How Getmomo, Germany’s digital banking platform for real estate, streamlined deposits and rent operations using Formance Ledger and Connectivity—live in 4 weeks. - [How Newton Trading Platform Achieves Reliable Transaction Tracking with Formance](https://www.formance.com/blog/customer-story/newton): How Newton scaled to $10M+ daily volume and 700K users with Formance Ledger—achieving low-latency performance, audit-grade traceability, and zero downtime. - [Fintech Society - Gérer des flux financiers complexes](https://www.formance.com/blog/podcast/222066a5-ef32-804e-9619-f15554354e76): Podcast episode (Fintech Society) on managing complex financial flows—external listening link archived in Formance’s podcast library. - [How Shares Leverages Formance to Scale Its Investing Platform](https://www.formance.com/blog/customer-story/shares): How Shares used Formance Ledger to scale money movement across brokers, PSPs, and e‑money accounts—supporting 1,000+ assets while cutting engineering load. - [Episode 168: Le Ledger qui aide FinTech et Plateformes à scaler leur back-end](https://www.formance.com/blog/podcast/222066a5-ef32-806b-9fa0-c7d7d1af221d): Podcastics episode with Anne-Sybille Pradelles on building a ledger to help fintechs and platforms scale their back-end—external listening link. - [Formance at Money20/20 2023, Europe’s Biggest Fintech Show](https://www.formance.com/blog/company/formance-at-money-2020-europes-biggest-fintech-show-2023): Why Money20/20 is high-leverage for fintech startups: networking strategy, event planning checklist, and the biggest themes we saw on the floor and on stage. - [The OSS Startup Podcast - Episode 89: Building the Open Source Cloud with Formance](https://www.formance.com/blog/podcast/222066a5-ef32-8015-a293-d9aa6dafa2c5): Episode 89 of the OSS Startup Podcast on Formance and building an open-source financial cloud—external link archived in the podcast section. - [New AWS Region: South Africa](https://www.formance.com/blog/company/new-aws-region-south-africa): Formance Cloud now supports the AWS South Africa region, letting you deploy closer to customers for lower latency—plus a preview of upcoming regions. - [Sifted - In 2022, female founders raked in some of Europe’s most high-profile fintech rounds](https://www.formance.com/blog/press/222066a5-ef32-80f1-beac-f3423100fa11): Sifted recap of major European fintech rounds involving female founders in 2022—archived reference link in Formance’s press section. - [Better Tech Podcast - Developing a winning strategy driven by e-payment innovations.](https://www.formance.com/blog/podcast/222066a5-ef32-80d7-ab8d-ec9bbf4edd1b): Better Tech Podcast episode on e-payment innovation strategy—external YouTube link archived in Formance’s podcast library. - [Sifted - Eight European startups tapped by Y Combinator to become the next big thing in fintech](https://www.formance.com/blog/press/222066a5-ef32-80fd-b44a-c7ef1b7f8fba): Sifted coverage of eight European fintech startups selected by Y Combinator—external link and reading reference in Formance’s press archive. --- # Glossary Full text of each entry is served at its URL with `Accept: text/markdown`. - [ACP (Agentic Commerce Protocol)](https://www.formance.com/glossary/acp): ACP (Agentic Commerce Protocol) - [Agent Wallet](https://www.formance.com/glossary/agent-wallet): Agent Wallet - [Agentic Payments](https://www.formance.com/glossary/agentic-payments): Agentic Payments - [AML (Anti-Money Laundering)](https://www.formance.com/glossary/aml-anti-money-laundering): AML (Anti-Money Laundering) - [AP2 (Agent Payments Protocol)](https://www.formance.com/glossary/ap2): AP2 (Agent Payments Protocol) - [Audit Trail](https://www.formance.com/glossary/audit-trail): Audit Trail - [Bi-temporality](https://www.formance.com/glossary/bi-temporality): Bi-temporality - [CASP (Crypto-Asset Service Provider)](https://www.formance.com/glossary/casp-crypto-asset-service-provider): CASP (Crypto-Asset Service Provider) - [CeDeFi (Centralized-Decentralized Finance)](https://www.formance.com/glossary/cedefi-centralized-decentralized-finance): CeDeFi (Centralized-Decentralized Finance) - [Color of Money](https://www.formance.com/glossary/color-of-money): Color of Money - [Core Ledger](https://www.formance.com/glossary/core-ledger): Core Ledger - [Custody / Custodian](https://www.formance.com/glossary/custody-custodian): Custody / Custodian - [Digital Asset](https://www.formance.com/glossary/digital-asset): Digital Asset - [ DORA (Digital Operational Resilience Act)](https://www.formance.com/glossary/dora-digital-operational-resilience-act): DORA (Digital Operational Resilience Act) - [Double-Entry Accounting](https://www.formance.com/glossary/double-entry-accounting): Double-Entry Accounting - [Fiat Currency](https://www.formance.com/glossary/fiat-currency): Fiat Currency - [Float](https://www.formance.com/glossary/float): Float - [Funds in Flight](https://www.formance.com/glossary/funds-in-flight): Funds in Flight - [Fungibility / Non-Fungibility](https://www.formance.com/glossary/fungibility-non-fungibility): Fungibility / Non-Fungibility - [General Ledger](https://www.formance.com/glossary/general-ledger): General Ledger - [GENIUS Act](https://www.formance.com/glossary/genius-act): GENIUS Act - [Idempotency](https://www.formance.com/glossary/idempotency): Idempotency - [Immutability](https://www.formance.com/glossary/immutability): Immutability - [Indemnity](https://www.formance.com/glossary/indemnity): Indemnity - [Issuer / Card Issuer](https://www.formance.com/glossary/issuer-card-issuer): Issuer / Card Issuer - [KYA (Know Your Agent)](https://www.formance.com/glossary/know-your-agent): KYA (Know Your Agent) - [KYC (Know Your Customer)](https://www.formance.com/glossary/kyc-know-your-customer): KYC (Know Your Customer) - [Liquidity Management](https://www.formance.com/glossary/liquidity-management): Liquidity Management - [MiCA Act](https://www.formance.com/glossary/mica-act): MiCA Act - [NBFI (Non-Bank Financial Institution)](https://www.formance.com/glossary/nbfi-non-bank-financial-institution): NBFI (Non-Bank Financial Institution) - [Omnibus Account](https://www.formance.com/glossary/omnibus-account): Omnibus Account - [Payment Mandate](https://www.formance.com/glossary/payment-mandate): Payment Mandate - [Payment Rail](https://www.formance.com/glossary/payment-rail): Payment Rail - [Payment Stablecoin](https://www.formance.com/glossary/payment-stablecoin): Payment Stablecoin - [Posting](https://www.formance.com/glossary/posting): Posting - [Prepaid Commit / Drawdown](https://www.formance.com/glossary/prepaid-commit): Prepaid Commit / Drawdown - [PSD2](https://www.formance.com/glossary/psd2): PSD2 - [Reconciliation](https://www.formance.com/glossary/reconciliation): Reconciliation - [Regulatory Reporting](https://www.formance.com/glossary/regulatory-reporting): Regulatory Reporting - [Settlement Finality](https://www.formance.com/glossary/settlement-finality): Settlement Finality - [SOC 2 / ISO 27001](https://www.formance.com/glossary/soc-2-iso-27001): SOC 2 / ISO 27001 - [Stablecoin ](https://www.formance.com/glossary/stablecoin): Stablecoin - [Sub-ledger](https://www.formance.com/glossary/sub-ledger): Sub-ledger - [System of Record](https://www.formance.com/glossary/system-of-record): System of Record - [Token Accounting](https://www.formance.com/glossary/token-accounting): Token Accounting - [Tokenization](https://www.formance.com/glossary/tokenization): Tokenization - [Transactional Outbox](https://www.formance.com/glossary/transactional-outbox): Transactional Outbox - [Virtual Card](https://www.formance.com/glossary/virtual-card): Virtual Card - [x402](https://www.formance.com/glossary/x402): x402