How NeoBanks and Fintech Payment Platforms Become a Financial Hub: The Architecture of Fiscal Intelligence
A technical breakdown of what it takes to move from transaction data to real-time business intelligence — and why the integration problem is harder than it looks
Key Takeaways
- Type B fiscal intelligence requires intersecting real-time transaction streams with SDI e-invoice documents to classify transactions according to Italian tax codes, VAT categories, and deduction rules, not just tracking amounts and dates.
- Building an accurate classification engine takes approximately five years of production data with continuous training from Italian commercialisti, achieving 85-90% automated accuracy and near 100% with human review loops.
- Italy's fiscal intelligence system must process five distinct data streams including CBI bank feeds, SDI invoices, government portal documents with PIN-only access, POS transactions, and expense receipts with varying protocols.
- The Italian SDI mandate has been operational since 2019 for mandatory B2B e-invoicing, creating the essential training corpus that makes automated fiscal classification possible across 28 document types.
- Neobanks and payment platforms possess real-time transaction data advantages over traditional banks but lack the classification layer needed to interpret fiscal and analytical meaning for merchant clients.
- The classification taxonomy for Italian businesses includes 28 SDI document types, 7 VAT nature code categories, 15+ TUIR deduction brackets, and over 300 government portal document types.
- The integration challenge is fundamentally a document intersection problem requiring jurisdiction-specific taxonomy knowledge, not a generic data enrichment task solvable with standard AI models or document scanners.
Summary
Neobanks and fintech payment platforms require a sophisticated classification layer that intersects transaction data with fiscal documents to provide meaningful business intelligence, a capability that cannot be quickly replicated. The core distinction is between Type A intelligence, which processes basic transaction streams showing amounts and dates, and Type B intelligence, which combines transaction data with document streams from Italy's mandatory SDI e-invoicing system to deliver full fiscal context including tax deduction codes, VAT classifications, and project attributions. Building this classification engine requires approximately five years of production data and continuous training from Italian commercialisti who correct low-confidence classifications, achieving 85-90% automated accuracy that approaches 100% with human review. The system must unify five distinct data streams: CBI bank feeds, SDI invoice streams for both issued and received invoices, government portal documents accessible only through PIN authentication, POS transaction data, and expense receipts, each with different access protocols and update frequencies. This integration challenge is fundamentally a document intersection problem rather than a simple data enrichment task, and the regulatory environment must be live long enough to generate the training corpus necessary for accurate fiscal classification across Italy's 28 SDI document types, multiple VAT nature codes, and 15+ TUIR deduction categories.
How NeoBanks and Fintech Payment Platforms Become a Financial Hub: The Architecture of Fiscal Intelligence
A technical breakdown of what it takes to move from transaction data to real-time business intelligence — and why the integration problem is harder than it looks
Paolo Messina | CEO, Mentally Digital LLC — San Jose, California
PhD Physics (EPFL), MBA (Michigan Ross)
Every neobank and payment platform operating in Italy already has a data advantage over traditional banks: real-time transaction feeds, clean CBI-standard bank data (Italy’s interbank data protocol), and a direct digital relationship with their merchant clients. What they don’t have is a classification layer — the component that tells the system what each transaction means, fiscally and analytically, for the business that generated it.
This sounds like a data enrichment problem. It is not. It is a document intersection problem, and the gap between the two framings determines whether a product team builds the right thing or the wrong thing.
The Two Intelligence Types — A Technical Distinction
Before anything else, a precise definition of the problem space.
Type A intelligence operates on transaction streams: amounts, dates, counterparties, categories inferred from merchant codes or payment descriptions. This is what bank data aggregation APIs produce. It is valuable, accurate, and real-time. It answers: “what happened, and how much?”
Type B intelligence operates on the intersection of transaction streams and document streams. The transaction tells you €18,400 (~$20,000 USD) left the account on March 12. The document — a passively received SDI invoice (Sistema di Interscambio, Italy’s mandatory B2B e-invoicing clearinghouse) — tells you it was for CNC machining services from a supplier in ATECO sector 25.62 (Italian business classification code for metalworking), classifiable under TUIR Article 102 (Testo Unico delle Imposte sui Redditi, Italy’s Consolidated Income Tax Act) as a fully deductible maintenance cost, attributable to commessa (project/job order) ORD-2026-0142 for client AutoTech Components, matched against DDT-0142 (Documento di Trasporto, Italian delivery note) which confirmed delivery on March 10. The bank transaction and the fiscal document describe the same economic event from two different angles. The intelligence emerges from their intersection.
This intersection is not achievable with a document scanner or a generic AI model. It requires a trained classification engine built on the specific taxonomy of the target fiscal jurisdiction — TUIR deduction codes, SDI natura VAT codes (Italian e-invoice VAT nature classification), ATECO sector mappings, F24 tributo codes (Italian unified tax payment form tribute codes), CU wage certificate structures (Certificazione Unica, Italy’s annual income certification). In Italy, that taxonomy has 28 document types (TD01 through TD28 in the SDI system), 7 VAT nature code categories each with subcategories, 15+ TUIR deduction brackets, and a government portal containing 300+ document types accessible only through PIN-authenticated delegation — not API, not OAuth, not any standard protocol.
The classification engine that handles this correctly was not built in a sprint. It was built over five years of production data, with a human review loop provided by practicing Italian commercialisti (Italian CPAs and business advisors who handle accounting, tax, and regulatory compliance) who correct low-confidence classifications and whose corrections feed back into model training. The accuracy profile that results from this process is approximately 85–90% on a fully automated basis. When the human review loop is applied to the residual uncertain classifications, effective accuracy reaches 100%. Over time, as the system accumulates transaction history with recurring suppliers and clients, automated accuracy improves further — the model learns that this specific supplier, at this price point, in this sector, always maps to the same classification.
This is the product that a neobank or payment platform cannot build by assembling a team and starting from scratch today. Not because the engineering is impossible, but because the training data requires the regulatory environment to have been live — and the Italian SDI mandate has been live since 2019, with mandatory B2B e-invoicing generating the corpus that makes the classification possible.
The Data Sources That Need to Be Unified
The complete fiscal intelligence picture for an Italian SMB requires five data streams, each with different access mechanisms and update frequencies.
1. CBI bank feed. The standard Italian interbank data protocol. Real-time or near-real-time. Every movement on every account the merchant holds. This is what neobanks and payment platforms already have in full.
2. SDI invoice stream — active and passive. Every invoice the merchant issues (active) and receives (passive) passes through the Sistema di Interscambio (Italian e-invoicing clearinghouse operated by the Agenzia delle Entrate, Italy’s Revenue Agency equivalent to the IRS) before it is legally valid. The structured XML of each invoice contains counterparty data, line items, amounts, VAT codes, document type codes, and references to upstream documents. This stream is available to any party the merchant authorizes to receive it.
3. Cassetto Fiscale (Italian Tax Drawer, the taxpayer’s government fiscal data portal). The Italian government’s fiscal data repository — this is the access point that neither banks nor neobanks can reach directly. It contains F24 tax payments actually made (not just declared), employee wage certificates (CU), all declarations filed, and extraction data from third-party sources. Access requires PIN authentication and a delegation from the merchant to a licensed fiscal intermediary. Banks cannot hold this delegation under Italian banking law. A non-banking technology platform operating as a fiscal intermediary can. This asymmetry is not a regulatory oversight — it is structural, and it means that the merchant’s complete fiscal picture is only available to partners who are not banks.
4. Payroll and INPS data. Wage certifications and INPS contribution flows (Istituto Nazionale della Previdenza Sociale, Italy’s National Social Security Institute), typically accessed via the Cassetto Fiscale or via direct integration with the merchant’s payroll provider. Necessary for complete cost classification and DSCR calculation (Debt Service Coverage Ratio, required under Italian crisis monitoring regulations).
5. Document chain — orders, DDT, invoices. The matching of purchase orders to delivery notes (DDT) to invoices creates the document chain that enables project-level margin accounting. ORD-2026-0142 → DDT-0142 → FT-2026/087 for client AutoTech Components at €18,400 (~$20,000 USD) green-status closed. ORD-2026-0155 → DDT-0155 → pending for MediDevice Italia at €12,800 (~$14,000 USD). ORD-2026-0161 → no DDT, no invoice for RailTech Systems at €34,500 (~$37,500 USD) red-status: revenue committed but not yet secured. This chain, visible in real-time, is what enables the CFO to know not just what has been invoiced, but what has been delivered and what is still at risk.
The Reconciliation Engine
The first output of combining bank feed and document streams is reconciliation: matching each bank movement to its corresponding fiscal document or obligation. In production across Italian SMBs, automated reconciliation achieves a success rate in the low-to-mid 90s percent across five transaction categories: invoice payments, tax payments (F24), payroll and INPS, financing (leasing, credit lines), and general utilities and miscellaneous. The residual unmatched transactions are either pending (the invoice hasn’t arrived yet) or require manual assignment.
The important technical note for a product team: the reconciliation success rate is not a fixed number. It depends heavily on data completeness — whether all five streams are connected, whether the merchant uses consistent supplier naming, whether invoice references appear in bank payment descriptions. A system with only the bank feed and the SDI stream will reconcile at a lower rate than one that also has Cassetto Fiscale data. Completeness of the input determines the quality of the output. This is the argument for integrating all five sources from the start rather than building incrementally.
The reconciliation layer is also where the integration architecture matters most for a neobank or payment platform. The bank data is already inside the platform’s infrastructure. The SDI stream is available through a Passepartout connection (Italian intermediary authentication system) or direct SdI API access. The Cassetto Fiscale data requires the PIN-delegated crawler — a periodic pull (daily or weekly) that fetches the merchant’s complete fiscal position from the government portal. The document chain requires either a direct integration with the merchant’s order management system or a document upload flow. None of these integrations are technically complex individually. The complexity is in maintaining all five simultaneously, detecting when one goes stale, and surfacing data quality indicators to the end user.
The Analytical Accounting Layer
Once the reconciliation engine is running on clean, complete data, the analytical accounting layer derives management accounting outputs without any ERP integration.
From the classified passive invoices: cost structure broken into fixed versus variable, production versus operational, by category and by supplier sector. A food service business produces a different cost structure than a mechanical manufacturing firm — the classification engine knows the difference from ATECO codes and invoice descriptions. From the imaged dashboards: a bar and food operation shows Coffee/food/beverages at 32%, Personnel at 28%, Rent/utilities at 16%, POS/payment fees at 6%, Equipment at 10%, Other at 8%. Fixed costs represent 36% of total; variable, 64%. Break-even: €1.62M (~$1.76M USD) per year. These outputs update with every invoice processed.
From the active invoices and the document chain: margins by revenue category. A precision manufacturing operation shows: CNC Line Alpha (Automotive) at 35% margin, Precision Parts (Aerospace) at 34%, Custom Tooling at 29%, Surface Treatment at 35%, Maintenance at 37%, R&D at 8%. Each line shows its data source and a reliability indicator — High for categories with complete document chains, Medium for categories where some matching is incomplete.
From the combination of both and the Cassetto Fiscale data: DSCR monitoring, IRES and IRAP projections (Imposta sul Reddito delle Società and Imposta Regionale sulle Attività Produttive, Italy’s corporate income tax and regional production tax) against the Italian tax calendar, and the D.Lgs 14/2019 crisis indicators (Italian Corporate Crisis and Insolvency Code requiring early warning systems) that 96.5% of Italian SMBs are currently not computing.
The accuracy profile for the analytical accounting outputs: approximately 85–90% in fully automated mode. Adding human review of low-confidence classifications brings this to effective 100%. Connecting an ERP data adaptor (bidirectional sync with the merchant’s accounting system) adds depreciation schedules, accruals, and detailed cost center allocation — upgrading accuracy further while the analytical layer remains the real-time signal source between ERP close cycles.
The Accountant Interface
The architectural decision that transforms a fiscal intelligence layer into a distribution flywheel is the separation of the merchant interface and the accountant interface.
Italian commercialisti manage between 100 and 200 SMB clients on average. If the platform gives the commercialista a dedicated access surface — separate login, aggregate view across all their clients, AI-powered research tools — the commercialista becomes a force multiplier rather than a bottleneck.
The accountant interface consists of three layers: a Financial Copilot for natural language queries on business data (“What margin do I make by service type? Show me the top 5 by revenue with estimated direct costs”), powered by multi-LLM routing with Claude Sonnet 4 and verified against the underlying structured data before delivery. A Legal and Tax Research module that takes a question (“Am I compliant with adequate structures?”) and decomposes it automatically into parallel searches — DSCR thresholds under Art. 13 D.Lgs 14/2019, debt/equity ratios under Art. 2086 c.c. (Italian Civil Code article on director duties for adequate organizational arrangements), INPS contribution delay alerts, director liability case law — returning 30 results across case law, statutes, and practice notes in seconds rather than the 45-minute manual research cycle it would otherwise require. And a Report Generation layer that produces client-ready output from the analytical data in minutes rather than hours.
The commercialista using this surface is not doing the same work faster. They are doing different work entirely — consulting rather than processing. When a single professional can handle 150 clients with the analytical depth previously possible for 30, the professional’s practice economics change. When their clients see outputs that were previously available only from Big Four advisory relationships, the professional’s market position changes. When the platform that enables this also happens to be where those clients bank, the adoption path from professional to client base is not a marketing campaign. It is a referral from a trusted advisor.
The Extension Architecture
The platform built for Italy extends to subsequent markets by swapping country-specific connectors while keeping the classification engine, reconciliation logic, analytical accounting, and accountant interface intact.
France (Factur-X/UBL, September 2026 mandate for large companies) requires a Chorus Pro API connector (France’s public invoicing portal) and a French TUIR equivalent (CGI, Code Général des Impôts, French General Tax Code) classification taxonomy. Germany (XRechnung, mandatory receive from 2025, send from 2027) requires an ELSTER certificate-based connector (Germany’s electronic tax declaration system). Both are structurally simpler than the Italian Cassetto Fiscale — they have modern APIs with structured responses rather than PIN-authenticated portal scraping.
The classification taxonomy is country-specific configuration, not country-specific engineering. The canonical fiscal model — company, counterparty, invoice, tax breakdown, payment, fiscal period — is identical across jurisdictions. The analytical accounting engine operates on the canonical model. The accountant interface operates on the analytical accounting engine. The only country-specific components are the connectors and the classification taxonomy. Everything else scales.
What This Means for a Product Roadmap
The integration sequence that maximizes time-to-value while minimizing development risk:
Phase 1 — Bank + SDI intersection. Connect the platform’s existing CBI bank feed to a passively received SDI invoice stream via authorized access. Build the basic reconciliation engine. This produces invoice-to-payment matching and a simplified cost view immediately.
Phase 2 — Cassetto Fiscale via fiscal intermediary delegation. Add the government portal data stream through a PIN-delegation architecture. This unlocks F24 matching, payroll reconciliation, and the complete fiscal position. Reconciliation success rate improves materially.
Phase 3 — Analytical accounting and compliance. Add the classification engine on the reconciled and enriched data set. This produces margins by category, fixed/variable structure, break-even, and DSCR monitoring.
Phase 4 — Accountant interface. Separate the professional access layer from the merchant dashboard. Enable multi-client aggregate views, AI research, and report generation. This activates the distribution flywheel.
Phase 5 — Country expansion. Add the France connector, the Germany connector, the Spain connector — each reusing the canonical model and the classification framework with country-specific taxonomy configuration.
The sequence is not optional. Each phase depends on the data quality of the previous phase. A platform that tries to build the analytical accounting layer before the reconciliation engine is clean will produce numbers that neither the merchant nor the accountant can trust. Trust is the product. The architecture is how you build it.
Paolo Messina is CEO of Mentally Digital, an AI fiscal intelligence engine built on five years of Italian production data with 300+ document types and multi-stream reconciliation.
For technical architecture discussions: info@mentally.ai
Data and Statistics
85–90%
100%
5 years
28
300+
2019
€18,400
5
Frequently Asked Questions
- Why can't neobanks easily build their own fiscal classification engine for Italian businesses?
- Building a fiscal classification engine requires five years of production data with a human review loop from practicing Italian commercialisti who correct low-confidence classifications. The training data depends on Italy's SDI mandatory B2B e-invoicing system that has been live since 2019. The taxonomy includes 28 SDI document types, 7 VAT nature code categories, 15+ TUIR deduction brackets, and 300+ government document types. Achieving 85-90% automated accuracy with this complexity cannot be accomplished by assembling a team and starting from scratch today, because the regulatory environment and corpus of classified transactions takes years to accumulate.
- What is the difference between Type A and Type B intelligence in fintech platforms?
- Type A intelligence operates on transaction streams and provides data on amounts, dates, and counterparties from bank feeds, answering what happened and how much. Type B intelligence operates on the intersection of transaction streams and document streams, combining bank data with fiscal documents like SDI invoices to understand the complete economic meaning of each transaction, including tax classification, project attribution, and regulatory compliance context. Type B intelligence requires integrating Italy's Sistema di Interscambio (SDI) e-invoicing data, TUIR tax codes, and ATECO sector classifications with real-time transaction data.
- What is the Cassetto Fiscale and why can't traditional banks access it?
- The Cassetto Fiscale is Italy's government fiscal data repository (Tax Drawer portal) containing F24 tax payments actually made, employee wage certificates (CU), all declarations filed, and third-party extraction data. Access requires PIN authentication and a delegation from the merchant to a licensed fiscal intermediary. Banks cannot hold this delegation under Italian banking law, creating a structural asymmetry. Only non-banking technology platforms operating as fiscal intermediaries can access this data, meaning the merchant's complete fiscal picture is exclusively available to non-bank partners.
- How does the document chain enable real-time project-level margin accounting?
- The document chain matches purchase orders to delivery notes (DDT) to invoices, creating visibility into project status. For example, ORD-2026-0142 matched to DDT-0142 and invoice FT-2026/087 shows a closed transaction with revenue secured. This enables CFOs to see not just what has been invoiced, but what has been delivered and what revenue is still at risk. A project with an order and DDT but no invoice shows pending revenue, while an order without a DDT or invoice indicates committed revenue that is not yet secured, providing real-time business intelligence beyond simple transaction tracking.
- What is the Sistema di Interscambio (SDI) and why is it critical for fiscal intelligence?
- The Sistema di Interscambio (SDI) is Italy's mandatory B2B e-invoicing clearinghouse operated by the Agenzia delle Entrate (Revenue Agency). Every invoice issued or received by Italian businesses must pass through SDI before it is legally valid. The structured XML of each invoice contains counterparty data, line items, amounts, VAT codes, document type codes (TD01 through TD28), and references to upstream documents. This system, mandatory since 2019, creates the corpus of classified transaction data necessary for building accurate fiscal classification engines and enables the intersection of transaction streams with document streams for Type B intelligence.
- What accuracy rate does a mature fiscal classification engine achieve for Italian tax compliance?
- A fiscal classification engine built over five years of production data with a human review loop from Italian commercialisti achieves approximately 85-90% accuracy on a fully automated basis. When the human review loop is applied to residual uncertain classifications, effective accuracy reaches 100%. Over time, as the system accumulates transaction history with recurring suppliers and clients, automated accuracy improves further because the model learns that specific suppliers at specific price points in specific sectors consistently map to the same classification under TUIR deduction codes and SDI natura VAT codes.
- What is automated reconciliation and what success rate does it achieve in Italian fintech platforms?
- Automated reconciliation is the process of matching each bank movement to its corresponding fiscal document or obligation by combining CBI bank feed data with SDI invoice streams and government fiscal data. In production across Italian SMBs, automated reconciliation achieves success rates in the low-to-mid 90s percent across five transaction categories: invoice payments, tax payments (F24), payroll and INPS contributions, financing (leasing and credit lines), and general utilities and miscellaneous expenses. Residual unmatched transactions are either pending (invoice not yet arrived) or require manual assignment.
- What are the five data streams required for complete fiscal intelligence of Italian SMBs?
- The five required data streams are: 1) CBI bank feed providing real-time transaction data on all merchant accounts, 2) SDI invoice stream containing all issued and received invoices through Italy's Sistema di Interscambio clearinghouse, 3) Cassetto Fiscale government portal containing F24 tax payments, employee wage certificates, and all filed declarations, 4) Payroll and INPS data for wage certifications and social security contributions, and 5) Document chain linking purchase orders to delivery notes (DDT) to invoices for project-level margin accounting. Each stream has different access mechanisms and update frequencies that must be unified.