Codat

Machine learning is real, shipped and material, and it is a layer on a pipe. Models trained across more than 100,000 businesses categorize bank transactions into spend and income classifications, using business rather than consumer categories. They also standardize charts of accounts so ratio analysis can run automatically, which is what turns a raw accounting feed into something an underwriter can use. Strip the models and the company's identity survives whole.

That identity is a universal integration to more than 20 accounting, banking and commerce platforms and a standardized schema, plus bidirectional write back and bank feeds. That was the original product and it remains most of what a lender buys. The enrichment sits inside the delivered product, not as tooling beside it.

Autonomy exposure is structurally low because the product supplies inputs and makes no decisions. The company is explicit that analysis ready data flows into the customer's existing underwriting systems and decisioning models. The judgment that does happen automatically is categorization, and the published account shows it unsupervised. No confidence score is exposed on a classified transaction, and no review queue exists for ambiguous entries.

No mechanism is described for a lender or a business to correct a miscategorized item. Data integrity checks are named as a feature and are a real control on completeness and consistency. They check whether the data holds together, not whether the model read it correctly.

One mechanism is real and one absence is clear. Data integrity checks are offered as a named product feature. They let an underwriter test whether the delivered financials are complete and internally consistent before relying on them. Missing is any measurement of the model itself: no categorization accuracy rate, no error analysis by platform or business type, no confidence exposure on individual classifications and no validation documentation. A lender using this output inside a credit model inherits an unmeasured component. Its own model risk function will be asked to validate a categorization layer it cannot see.

One institution is named, and it is a substantial one: BMO, launch partner for the Insights suite when the advisory intelligence tier for commercial banking launched in May 2026. The training base is a second checkable scale figure, with models trained across more than 100,000 businesses. Integration timelines are stated concretely at four to eight weeks for most lenders, which a reference call can test immediately.

Against that, no other institution is named, and no volume of businesses connected or loans underwritten is published. No outcome figure exists for approval rates, time to funding or underwriting cost, though those are the stated benefits. The company has been operating since 2017, so the absence of measured customer outcomes is a choice rather than a stage of life.

The training arrangement is disclosed in passing and never governed. Models are stated to be trained across more than 100,000 businesses. Categorization therefore improves for every customer using financial data supplied through other customers' borrowers, which is cross customer learning by construction. Nothing published states whether the training data is aggregated and de identified, or whether a lender can opt its connected businesses out.

Nor does it say whether the consenting business is told its data trains a shared model, or what a competing lender on the same platform benefits from. Some contributory database vendors market their pooling openly. Here it appears only as a capability statement about model quality.

Privacy rests on architecture rather than policy. Connections run through authorization flows requiring the business's explicit consent, and the company states plainly that it never stores banking credentials. The access token model replaces credential custody entirely. Encryption is named, and GDPR is named as applying. The defining property is who consents.

The small business whose accounting, banking and commerce data is pulled authorizes the connection itself and can withdraw it, so the data subject is a party to the arrangement, not an unwitting one. In many data products the person being profiled has no relationship with the vendor and no knowledge of it. No retention schedule, subprocessor list or deletion commitment is published.

Codat names its security frameworks rather than gesturing at them. It describes ISO 27001 in its current revision as held, with a current certificate of registration, alongside a SOC Type II certification. The company also names 256 bit encryption and GDPR. The consent architecture reinforces this. Credentials are never stored and access runs through revocable authorization, which removes the highest value target from the vendor's estate entirely. A buyer can name and check both frameworks without entering a sales conversation.

GDPR is named as applying, and no other supervisor, statute, rule or admission process appears. The gap is specific to this vendor type. A business supplying bank feeds into accounting software and pulling banking data on consent operates adjacent to the regulated data access regimes in its two main markets. Those regimes carry their own authorization and conduct requirements.

Nothing published states which of them apply, whether any registration is held, or how the consent flow maps to their standards. Codat holds no lending or banking license and needs none as a technology supplier.

Codat supplies the inputs to credit decisions rather than making them, but the exposure is real and one layer removed. A model that categorizes revenue and expenses determines the ratios an underwriter reads. A misclassification changes an approval outcome without anyone seeing a model in the decision. Categorization accuracy will not be uniform. Models trained across a pool of businesses perform worst on the business types least represented in it.

That correlates with sector novelty and size, informal record keeping and non standard accounting conventions, and those are the businesses already least well served by credit. No per sector or per platform accuracy is published, and no analysis of where categorization degrades.

The vendor makes no commercial commitment to its output: no guarantee or indemnity on categorization quality is published. The real control sits with the party whose data is at stake. The business grants access through an authorization flow it initiates and understands, and it can withdraw that connection. The subject can end the data relationship unilaterally, without petitioning anyone.

On the buyer side, data integrity checks give a lender a way to detect defective input before acting on it. Neither reaches the borrower whose ratios were computed from a miscategorized ledger and who was declined on that basis. Nothing describes correction of a classification, or notification that one drove an outcome.

The data half of the chain is enumerated in detail. More than 20 source platforms are named individually across accounting, commerce and payments, so a buyer can establish exactly where each field originates and which upstream systems its underwriting depends on. That disclosure is published, not offered on request. The models are described as the company's own, trained on its accumulated data, which shortens the chain at the point that matters.

Not stated is whether any external model provider takes part in categorization or in the newer analytical products. No subprocessor list is published either, and that is the remaining question a bank examiner would put.

Integration is the product, and it is documented in full. More than 20 platforms are named individually across accounting, commerce and payments, including the major small business ledgers and marketplace and commerce systems, all reached through one integration. The connection is bidirectional, not read only. Bills, payments and expenses write back into the connected platform, and bank feeds push transactions the other way.

Software development kits are published in five named languages, alongside full public documentation and machine readable interface specifications. Typical lender integration is stated at four to eight weeks. A buyer can evaluate the entire integration surface without contacting sales.

Residency goes unstated. No hosting provider or region selection is published, and no residency commitment or private deployment option. GDPR is named as applying, which implies European handling arrangements exist, but naming a regime is not a residency statement. The question is live for a vendor headquartered in the United Kingdom that sells to United States lenders and holds small business accounting and banking records on both sides. Nothing published tells a buyer where connected business data rests or whether it can be constrained.

Neither tier publishes pricing, packaging or a basis of charge. The natural units for this product, per connected business, per data pull or per platform, produce very different economics for a lender monitoring a portfolio continuously rather than pulling data once at application. Continuous monitoring is explicitly marketed, so a buyer cannot tell whether the cost of the product scales with the frequency of the behavior the vendor is encouraging.

The buyer set is wide. The documentation states that the lending solution caters to financial institutions of any size, naming digital lenders, banks and neobanks, plus corporate card providers and payment providers. The Insights tier adds a second buyer inside the same institution, selling working capital, spend and foreign exchange analysis to commercial bank card and treasury teams rather than to credit. Serving both the credit and treasury functions of the same bank is real breadth.

Geography is not evidenced. The company operates from the United Kingdom with an evident United States presence, and no coverage in other regions is demonstrated. That matters because the underlying accounting platform mix differs sharply outside those markets.