Transaction categorisation APIs: what to compare and how to test them

For Australian banking applications, compare native transaction categories and income insights as separate capabilities. Fiskil documents native categorisation in its transaction workflow and a separate Income API derived from enriched transactions. Evaluate the outputs your application needs, the account coverage and the handling of uncertain results.

A spending chart, an income-assessment workflow and a bookkeeping product can receive the same transaction but need different interpretations. A useful evaluation starts with the decision the category will support.

What Fiskil supplies, and what your application decides

Fiskil's go-live checklist describes transaction categories and links to the taxonomy. Its Income guide describes a separate income profile, including detected sources, frequency and amounts. Those capabilities should be evaluated independently.

Requirement	Documented starting point	What to validate
Group transactions for a spending view	Native transaction categories and the published taxonomy	Returned fields, unknown labels and your category mapping
Investigate recurring income	Income insights derived from enriched transactions	Which credits form a stream, required history and the meaning of amount estimates
Make a lending or accounting decision	Your application rules and review process	Exclusions, disputed records and the consequences of an incorrect interpretation

A category label is not a completed affordability assessment. A recurring credit is not, by itself, proof of employment or sustainable income. Ask Fiskil to demonstrate the particular output against a representative, appropriately governed test set. For setup, use the sandbox testing guide.

Separate source records, enrichment and your own interpretation

A bank description, an enriched merchant name and a spending category are different kinds of information. A transaction type can describe how money moved without explaining why the customer spent it. A merchant category may also be too broad for an accounting or lending decision.

Fiskil's go-live checklist documents native transaction categorisation through a categories object and links to its taxonomy. The transaction endpoint also documents category-based filtering. Inspect the current response and category definitions before mapping them into your product.

Do not invent a category code or assume an example application label is an actual Fiskil output.

The public Fiskil category taxonomy includes, for example:

Actual taxonomy code	Interpretation to validate in your application
INCOME_SALARY	Employment-related inflows
INCOME_BUSINESS	Business-related inflows
INCOME_CASH_ADVANCES_AND_LOANS	Borrowed money, which should not automatically become earned income
TRANSFER_IN_ACCOUNT_TRANSFER	Inbound account transfers, requiring context for higher-level analysis

The presence of these labels does not make every inflow suitable for a credit or accounting decision. It gives your implementation a documented vocabulary to test and map.

Which providers offer transaction categorisation?

Fiskil documents native transaction categories. Basiq's API introduction describes a separate Enrich area including categorisation and transaction classification. Compare the precise proposed service, including whether enrichment is bundled or separately scoped.

For an Australian banking-data application, we recommend evaluating Fiskil against a representative sample of your required transactions. A good buying decision connects the category output to your application workflow and operating cost.

Build a test set your team can explain

Use authorised, appropriately governed data or clearly synthetic examples. Define a reference label through a documented review process and keep disputed cases separate from clear ones.

Include different institutions, payment descriptions, transaction types and customer situations. Test uncommon cases deliberately rather than allowing frequent supermarket purchases to dominate the evaluation.

Synthetic example	Question to test
Supermarket transaction	Is the category useful for this product's definition of household spending?
Payment processor description	Does the output identify the merchant sufficiently, or preserve uncertainty?
Transfer between the customer's accounts	Can the application avoid treating it as spending or new income?
Refunded purchase	Does the product reverse or otherwise account for the original interpretation?
Business equipment purchase	Is a consumer-spending label suitable for the accounting decision?
Unfamiliar or ambiguous description	Can the application handle an unknown result without forcing certainty?

The questions above are test-design examples, not assertions that the API will infer each fact automatically.

Measure more than overall agreement

Create your own evaluation report with at least four views:

• Coverage: how many records have the fields and classifications your product requires?
• Agreement by category: where does the result match the reviewed reference labels, and where does it differ?
• Unknown and ambiguous cases: how often does the product need another source or a user correction?
• Business impact of errors: which mistakes materially affect the customer or operational decision?

If you calculate an agreement rate, publish the denominator, sample selection, category definitions and treatment of disputed labels. Call it a result for that test set, not a guaranteed production accuracy rate.

Separate the API's output from your mapping rules. Otherwise a mistake in your own category-to-product mapping can be incorrectly attributed to the provider.

Keep a versioned mapping layer

A budgeting app might combine several provider categories into one visible group. An accounting workflow might require a separate review before mapping a category to a ledger code. Record that distinction explicitly.

A useful internal mapping record contains the original category, the visible application label, mapping version and any approved correction. Apply retention controls to the underlying data and avoid copying complete payloads into general logs.

If the provider updates a taxonomy, test how the change affects existing views and calculations. Decide whether historical displays should preserve their earlier interpretation or be recalculated. Make the choice visible to the teams relying on the output.

Treat categories as evidence for higher-level analysis

Income assessment needs more than a salary-looking description. Reconciliation needs ledger relationships as well as transaction labels. A recurring-payment feature needs a definition of recurrence and a way to handle interruptions or changed amounts.

These are valuable application features, but they should not be implied by the presence of a categorised transaction alone. Confirm which analysis the provider supplies and which logic your own product operates.

Move from a demo to a production decision

Ask for the current taxonomy, relevant response examples, sample coverage, change policy and a clear commercial scope. Test category retrieval alongside pagination, data readiness and the real customer connections your service requires.

Fiskil offers the data connection and documented category capabilities to start that work. Bring your evaluation cases to the team, then validate the result against the decisions your app needs to make. That produces a useful comparison and a more defensible product than repeating an unsupported accuracy percentage.