When a Spiko bank account is read
Pulls the holder's Spiko bank account with IBAN, BIC, currency, and holder name.
Read Spiko bank accounts and their payment details into Well over the Well-hosted Spiko MCP server. Each account resolves with its IBAN, BIC, currency, and holder, ready to sit beside your other connected accounts.
Spiko feeds bank account, payment detail, document into Well as a source. The connection is read-only; disconnect at any time from your workspace settings to revoke Spiko’s access.
| From Spiko | In Well | Relation | |
|---|---|---|---|
| Bank account | Workspace account | Becomes | |
| Payment detail | Payment instrument | Resolves to | |
| Document | Workspace document | Indexes as |
Pulls the holder's Spiko bank account with IBAN, BIC, currency, and holder name.
Resolves the account IBAN from the same Spiko bank account record so a payment instrument can be matched.
Connect Spiko over OAuth (MCP DCR via Well): Well registers a client through Spiko's OAuth Dynamic Client Registration and you approve on Spiko's side, so the password never reaches Well; Well holds only a scoped token it can refresh.
Well brings bank account, payment detail, and document in from Spiko on live events backed by periodic reconciliation reads. The first sync backfills history in the background and the connection stays live after.
Well resolves each Spiko entity into workspace account, payment instrument, and workspace document, assigns categories, and links every record to an audit trail across the rest of your connected tools.
Your data from Spiko lands in the workspace as workspace account, payment instrument, and workspace document you can search, chart, and automate.
Ask in plain language. Well answers from your connected Spiko connection, resolved against the rest of your stack.
Ask anything about your Spiko connection
Ask about your Spiko connection…
Choose Spiko in Well's Connections panel. Well opens the Spiko MCP server through an OAuth flow proxied at Well's Spiko endpoint, registering a client via Dynamic Client Registration so there is no secret to paste; you approve the read access on the consent step.
Well reads your Spiko bank accounts with holder, IBAN, BIC, and currency, plus the payment details tied to them and any exposed documents, mapping each into the workspace as a structured record.
The bank accounts sit beside your other connected accounts for querying and matching. Account-level transactions are not read today (a cross-tool resolver is on the roadmap) and crypto-wallet reads are blocked, so only fiat bank-account data serves the account entity.
The MCP handshake completes in about a minute. Bank accounts and payment details read on connect; transaction reads are a roadmap item, not live.
Spiko connects through the Well-hosted MCP server with OAuth Dynamic Client Registration proxied at Well's Spiko endpoint, so Well never stores a Spiko secret. The grant is read-only and, by design, narrow: it serves bank-account and payment-detail data, while account-level transaction reads stay on the roadmap and Ethereum-wallet reads are blocked. The token reads fiat account data and nothing it could change in Spiko.
Read Spiko records
Resources the Spiko MCP server exposes, scoped by your OAuth approval.
Resolve bank account, payment detail, and document across your stack
Match identifiers in Spiko against the same entities your other connected tools expose, so each record carries cross-tool context.
Modify or delete Spiko records
Not granted; Spiko is read-only in Well. Write-back is opt-in per connector when a write surface exists.
Store Spiko passwords or session cookies
Authentication runs through OAuth (MCP DCR via Well) tokens we never see.
Pick Spiko in Well's Connections panel and authorise through the Well-hosted Spiko MCP server. The OAuth flow is proxied via Well's Spiko endpoint and uses Dynamic Client Registration, so you approve access on the consent step without pasting a key. Well registers itself and the read connection opens from there.
Well reads your Spiko bank accounts (the holder, IBAN, BIC, and currency) and the payment details tied to them, plus any documents Spiko exposes, and brings each into the workspace as a structured record. The bank-account and payment-instrument data is what flows; that is the slice of Spiko this connector serves into Well.
No. Account-level transaction reads are held back today, pending a cross-tool resolver that ties a transaction to the right account, so movements do not flow yet; bringing them in is on the roadmap. Ethereum-wallet account reads are blocked outright, so only fiat bank-account data serves the account entity. What you get is the bank-account and payment side, not a transaction feed or a wallet balance.
You can see each Spiko bank account beside the rest of your connected accounts, with its IBAN, BIC, currency, and holder resolved, and use the payment details to match an instrument when reconciling against another source. Because the account is structured in the workspace, it sits in the same place you query your other banking relationships, ready for matching once transaction reads land.
Well reads Spiko over the MCP connection in the background and refreshes the bank-account and payment-detail records as they change on the Spiko side, with the first connect bringing in the current set. Querying works on what has synced. Spiko stays the source of truth; Well keeps a structured, read-only copy.
Disconnect Spiko in Well and the MCP token is dropped, so Well stops reading your bank accounts and payment details immediately. The connection was read-only throughout, so there is nothing written to Spiko to reverse. The account records Well already mirrored stay queryable in your workspace until you ask Support to clear them.
More in Treasury
Popular cross-category
Connect once. Every bank account, payment detail, document from Spiko becomes searchable, queryable, and ready for your agents and tables. Disconnect any time.