Skip to main content
Audact
See the offer

Integration · finAPI

Know whether they paid, before you ask.

Planned · no date set

finAPI aggregates PSD2 account data across nearly every DACH bank and bridges it into DATEV-canonical bookkeeping. Under its own licence, not ours. One integration on our side reaches hundreds of financial endpoints on yours, and the value in a call is blunt: an agent that knows the invoice was settled yesterday does not ring to ask about it.

What the agent checks before the call

{
  "tool": "finapi_payment_status",
  "arguments": { "invoice_ref": "RE-2026-00841" },
  "result": {
    "status": "settled",
    "settled_on": "2026-08-14",
    "source": "psd2_account_lookup"
  },
  "effect": "campaign_entry_suppressed"
}

Worked example. Acme GmbH and Nova Industries are fictional; no customer data appears here.

A suppressed call is still an event: the suppression is recorded with its reason, so a campaign can account for what it did not do.

What applies around the data

Account information services may only access payment account data with the explicit consent of the payment service user.
Directive (EU) 2015/2366 (PSD2), Art. 67
Financial entities must manage and report ICT-related incidents.
Regulation (EU) 2022/2554 (DORA), Art. 17 · applicable since 17 January 2025
The person must be told they are speaking to an AI system.
Regulation (EU) 2024/1689, Art. 50(1)

What Audact governs around it

Outbound eligibility before every dial, independent of what the bank data says.
In controlled testing · Germany: national policy layer active. Netherlands: in development. Belgium and Austria: planned.
Article 50 disclosure at the top of the call, recorded.
In controlled testing
Suppression recorded with its reason, so a campaign accounts for its silences.
In controlled testing
PSD2 account lookup and the DATEV bridge through finAPI.
Planned

Sector

The most expensive call is the one you should not have made.

Receivables campaigns run on data that is a day or a week old, which produces the call that annoys the customer who already paid. Bank data closes that gap, and the difference shows up in complaints long before it shows up in collections.

It pairs with the planned DATEV and lexoffice integrations: finAPI supplies the payment truth, the ledger supplies the invoice, and the governed call sits between them.

Setup

Four steps, once the integration ships.

  1. Connect finAPI with your own subscription and the consents it requires.
  2. Map accounts to the client records the campaign draws from.
  3. Set the suppression rules: settled, partially settled, disputed.
  4. Run the campaign in shadow mode and read what would have been suppressed.

Questions

Whose consent carries the bank lookup?
The account holder's, given to finAPI under PSD2. Audact never holds bank credentials and never sees them; it receives the status, not the account.
Is the finAPI subscription included?
No. Nothing to order. A connection is scoped inside an applicable paid agreement; integrations are not priced separately. The finAPI subscription stays between you and finAPI.

Do not wait for the integration

Every integration will be built on the same six endpoints. They run inside the managed platform; no public API is served on api.audact.ai yet, apart from the published Merkle roots. Where a sector system exposes an API, the shorter route is to call it from your side and let Audact govern the conversation.

See the API

Related