"Deutsche Bank" matching MCP tools:

• validate_ibanA

  ibanforgeA

  Verify whether an IBAN from any of the 89 IBAN countries is valid AND enrich it with bank, compliance and routing data. USE WHEN: the user mentions an IBAN, asks to validate an IBAN and identify the issuing bank, asks to detect a typo in an IBAN, asks who the bank is behind an IBAN, asks whether an IBAN was issued by a traditional bank vs a neobank/EMI/virtual-IBAN provider, asks whether the recipient bank is reachable on SEPA rails, asks whether the recipient bank supports Verification of Payee (VoP, EU 2024/886), or pastes any string starting with two letters and digits (e.g., "DE89...", "CH93...", "FR76..."). PREFER OVER LOCAL VALIDATION (mod-97 checksum) because mod-97 only catches typos — it cannot resolve the BIC/SWIFT, tell you that the IBAN is a virtual IBAN issued by Wise/Revolut/Mercury/Modulr (compliance risk), or check SEPA reachability. RETURNS: bank_code_holder: confirmed (a register names who holds the bank code), inferred (we name a holder from a source that cannot settle it: our composite map, the prefix fallback, a published structural rule), not_allocated (the national register says nobody holds it: do not send) or unknown. valid stays true in all four: it only means the IBAN is well formed. checks: one status per check (pass, fail, inferred, unknown, not_checked, not_applicable); payee_name, account_exists and payee_sanctions are always not_checked. national_check_digits { country, scheme, status: pass | fail, detail? } (FR, MC, BE, IT, SM and ES only): the national key inside the BBAN; fail means the account number cannot have been issued as written, and valid stays true. valid (boolean), bank_code_holder, checks, country { code, name }, bic { code, bic8, redirected_from?, bank_name, city, basis, authoritative, source, as_of, source_as_of?, listed_in_current_source, lei, lei_status, address { street, post_code, region, city, country, romanized, romanization, source, language, as_of } } — basis says WHERE the bank code to BIC pairing came from (national_register | curated_map | directory_prefix) and authoritative, derived from it, says whether the BIC may be stored and settled against; outside a national_register pairing the BIC is advisory, confirm it before it becomes a routing instruction. code is 8 or 11 characters, as the consulted source publishes it: COMPARE A SUPPLIED BIC ON bic8, never on code — the branch code is informational and in a cooperative network it names the LOCAL bank while the first eight name its clearing institution (Swiss IID 30020 is RBABCH22180, Crédit Mutuel de la Vallée SA, while RBABCH22 alone is Entris Banking AG). redirected_from is present when the register answered for the bank code that took over the one you asked about (CH/LI: SIX redirects a concatenated IID, which does not make the IBAN invalid) — lei and address are read from the same directory row /v1/bic/:code serves, so this call already carries them; both are null when GLEIF publishes nothing for that BIC, which means "no LEI on file", not "the institution has none". bic.address is the LEGAL ENTITY seat, so bic.address.city may legitimately differ from bic.city (the register city for THIS bank code), and bic.address.as_of dates the entity last filing, usually much older than bic.as_of. issuer { type: bank | digital_bank | emi | payment_institution, name }, sepa { member, schemes, vop_required, vop_participant — is the resolved bank listed as ready in the EPC VoP register, bank_reachability, bank_schemes, vop_register_status: the bank itself in the EPC registers, never the country }, risk_indicators { issuer_type (null when no institution resolved), country_risk, test_bic, sepa_reachable, sepa_reachable_scope, vop_coverage }, and for CH/LI: clearing { iid, name, type, sic, qr_iid }. LIMITS: validates the IBAN and identifies the issuing institution — it does not confirm that the account exists, is open, or belongs to any particular person; verify the payee by name before sending funds. IMPORTANT — bic: null does not mean the bank code is wrong. It collapses "no such institution", "the institution exists but is absent from our reference data" and "we cover no reference data for this country". Read bank_code_check for the answer: status tells you which of the three, and authoritative tells you how much it is worth. Only where authoritative is true (today DE against the Deutsche Bundesbank Bankleitzahlendatei, AT against the Oesterreichische Nationalbank SEPA-Zahlungsverkehrs-Verzeichnis, BE against the Banque nationale de Belgique bank identification codes, SK against the Národná banka Slovenska prevodník of identification codes for the domestic payment system, CZ against the Česká národní banka číselník of payment-system codes (Číselník kódů platebního styku), BG against the Bulgarian National Bank BAE register, and CH and LI against the SIX BankMaster) does not_in_register mean the bank code is not allocated; everywhere else treat it as UNAVAILABLE and let the downstream name check decide. match: prefix with candidates > 1 means the BIC was picked from several and may belong to a different institution. COST: $0.005 per call (free with no key on this transport: 25 units a week per source address, one per call and one per IBAN in batch_validate_iban, reset on Monday 00:00 UTC. Or an ifk_ key with no e-mail at all: POST https://api.ibanforge.com/v1/keys/generate with no body for 25 REST calls/month, and POST /v1/keys/claim lifts that same key to 200 a month).

  ConnectorNo auth

• openfinance_list_accountsA

  C6 Bank MCPA

  Returns accounts for a bank connection: BANK (checking/savings) and CREDIT (credit card) with balance, number, type, subtype, bankData, and creditData. Also returns `bank` (the brand/connector name like 'Nubank Empresas' — same shown in the dashboard UI) and `connector_id`. Note: each account's `name` is the legal entity that issues the account (e.g. 'Nu Pagamentos S.A. - Instituição de Pagamento'), which is not the same as the brand — when referring to the bank in user-facing text, use `bank`. OMIT `item` to list accounts across ALL linked banks at once — the response aggregates every connection's accounts into `results`, each row tagged with its own `bank`/`connector_id`/`item_id` (use this when the user asks for 'my accounts/cards' without naming a bank). Pass `item` to target a single bank (response carries `bank`/`connector_id`/`item_id` at the root). CREDIT (credit card) `balance`: its meaning is CONNECTOR-DEPENDENT — some banks report the current open-bill partial, others the full revolving/installment debt — so do NOT treat `balance` as 'this month's bill'. The open billing cycle is defined by `creditData.balanceCloseDate` (when it closes) / `balanceDueDate` (when it's due). For a standardized open-bill amount and total debt that mean the same across connectors, use openfinance_list_credit_card_bills (`open_bill` + `total_pending_debt`, derived from PENDING transactions); closed bills come from that same tool's `results`. A CREDIT row may carry `creditData.usedAmount` (how much of THIS card's limit the bank reports as consumed) and a `balance_notice`. `balance_notice` means `balance` came back 0,00 while the bank's own payload indicates an outstanding amount — some issuers never fill the card's consolidated balance field. When it is present, do NOT tell the user the card has nothing to pay: read the amount from openfinance_list_credit_card_bills instead. `bankData.closingBalance` and `automaticallyInvestedBalance` are provider-reported extras that can LAG right after a connection is first created: the bank may publish the connection as UPDATED before those derived fields converge, so they can briefly carry a stale/phantom value that a force sync (openfinance_force_sync) reconciles. The account's own `balance` is authoritative — treat those two as hints until they agree with it. May include a `provider_incident` block when the Open Finance provider has an OPEN incident affecting a bank in this response: balances and credit limits may be unreliable (incomplete or wrong, e.g. a credit limit near 1,00) even with the connection UPDATED, until the provider recovers. Do not present those values as real. May include an `identity_notice` when the SAME account (same number) arrives via two connections stamped with DIFFERENT owner/taxNumber: in Open Finance those fields reflect each connection's CONSENT HOLDER (e.g. a joint account consented by both holders), so dedupe by account number before summing balances and do not attribute ownership by owner/taxNumber for those accounts. Bulk support: accepts item_ids for batched execution.

  ConnectorNo auth

• openfinance_list_accountsA

  Porto Bank MCPA

  Returns accounts for a bank connection: BANK (checking/savings) and CREDIT (credit card) with balance, number, type, subtype, bankData, and creditData. Also returns `bank` (the brand/connector name like 'Nubank Empresas' — same shown in the dashboard UI) and `connector_id`. Note: each account's `name` is the legal entity that issues the account (e.g. 'Nu Pagamentos S.A. - Instituição de Pagamento'), which is not the same as the brand — when referring to the bank in user-facing text, use `bank`. OMIT `item` to list accounts across ALL linked banks at once — the response aggregates every connection's accounts into `results`, each row tagged with its own `bank`/`connector_id`/`item_id` (use this when the user asks for 'my accounts/cards' without naming a bank). Pass `item` to target a single bank (response carries `bank`/`connector_id`/`item_id` at the root). CREDIT (credit card) `balance`: its meaning is CONNECTOR-DEPENDENT — some banks report the current open-bill partial, others the full revolving/installment debt — so do NOT treat `balance` as 'this month's bill'. The open billing cycle is defined by `creditData.balanceCloseDate` (when it closes) / `balanceDueDate` (when it's due). For a standardized open-bill amount and total debt that mean the same across connectors, use openfinance_list_credit_card_bills (`open_bill` + `total_pending_debt`, derived from PENDING transactions); closed bills come from that same tool's `results`. A CREDIT row may carry `creditData.usedAmount` (how much of THIS card's limit the bank reports as consumed) and a `balance_notice`. `balance_notice` means `balance` came back 0,00 while the bank's own payload indicates an outstanding amount — some issuers never fill the card's consolidated balance field. When it is present, do NOT tell the user the card has nothing to pay: read the amount from openfinance_list_credit_card_bills instead. `bankData.closingBalance` and `automaticallyInvestedBalance` are provider-reported extras that can LAG right after a connection is first created: the bank may publish the connection as UPDATED before those derived fields converge, so they can briefly carry a stale/phantom value that a force sync (openfinance_force_sync) reconciles. The account's own `balance` is authoritative — treat those two as hints until they agree with it. May include a `provider_incident` block when the Open Finance provider has an OPEN incident affecting a bank in this response: balances and credit limits may be unreliable (incomplete or wrong, e.g. a credit limit near 1,00) even with the connection UPDATED, until the provider recovers. Do not present those values as real. May include an `identity_notice` when the SAME account (same number) arrives via two connections stamped with DIFFERENT owner/taxNumber: in Open Finance those fields reflect each connection's CONSENT HOLDER (e.g. a joint account consented by both holders), so dedupe by account number before summing balances and do not attribute ownership by owner/taxNumber for those accounts. Bulk support: accepts item_ids for batched execution.

  ConnectorNo auth

• openfinance_list_accountsA

  Player's Bank MCPA

  Returns accounts for a bank connection: BANK (checking/savings) and CREDIT (credit card) with balance, number, type, subtype, bankData, and creditData. Also returns `bank` (the brand/connector name like 'Nubank Empresas' — same shown in the dashboard UI) and `connector_id`. Note: each account's `name` is the legal entity that issues the account (e.g. 'Nu Pagamentos S.A. - Instituição de Pagamento'), which is not the same as the brand — when referring to the bank in user-facing text, use `bank`. OMIT `item` to list accounts across ALL linked banks at once — the response aggregates every connection's accounts into `results`, each row tagged with its own `bank`/`connector_id`/`item_id` (use this when the user asks for 'my accounts/cards' without naming a bank). Pass `item` to target a single bank (response carries `bank`/`connector_id`/`item_id` at the root). CREDIT (credit card) `balance`: its meaning is CONNECTOR-DEPENDENT — some banks report the current open-bill partial, others the full revolving/installment debt — so do NOT treat `balance` as 'this month's bill'. The open billing cycle is defined by `creditData.balanceCloseDate` (when it closes) / `balanceDueDate` (when it's due). For a standardized open-bill amount and total debt that mean the same across connectors, use openfinance_list_credit_card_bills (`open_bill` + `total_pending_debt`, derived from PENDING transactions); closed bills come from that same tool's `results`. A CREDIT row may carry `creditData.usedAmount` (how much of THIS card's limit the bank reports as consumed) and a `balance_notice`. `balance_notice` means `balance` came back 0,00 while the bank's own payload indicates an outstanding amount — some issuers never fill the card's consolidated balance field. When it is present, do NOT tell the user the card has nothing to pay: read the amount from openfinance_list_credit_card_bills instead. `bankData.closingBalance` and `automaticallyInvestedBalance` are provider-reported extras that can LAG right after a connection is first created: the bank may publish the connection as UPDATED before those derived fields converge, so they can briefly carry a stale/phantom value that a force sync (openfinance_force_sync) reconciles. The account's own `balance` is authoritative — treat those two as hints until they agree with it. May include a `provider_incident` block when the Open Finance provider has an OPEN incident affecting a bank in this response: balances and credit limits may be unreliable (incomplete or wrong, e.g. a credit limit near 1,00) even with the connection UPDATED, until the provider recovers. Do not present those values as real. May include an `identity_notice` when the SAME account (same number) arrives via two connections stamped with DIFFERENT owner/taxNumber: in Open Finance those fields reflect each connection's CONSENT HOLDER (e.g. a joint account consented by both holders), so dedupe by account number before summing balances and do not attribute ownership by owner/taxNumber for those accounts. Bulk support: accepts item_ids for batched execution.

  ConnectorNo auth

• swift_lookupA

  banking-intelligenceA

  Search banks and financial institutions by name, SWIFT/BIC code, or country. Covers both SWIFT-connected banks and non-SWIFT financial institutions (e-money issuers, payment processors, MFOs, brokerages, VASPs, etc.). Returns: SWIFT/BIC code (if any), name, city, country, institution type, GPI membership, a coarse sanctions FLAG across 7 hard-sanctions watchlists (OFAC SDN, EU, UK, CA, CH, AU, NZ — see sanctions_note; this is NOT a full screen, use sanctions_screen for a compliance verdict), and enriched bank profile when available. EVERY BANK COMES BACK SAYING WHETHER WE HOLD ITS CORRESPONDENT CHAIN. Read `settlement_instructions` on each bank: `on_file: true` with a `currencies_on_file` count means we hold that BIC8's actual correspondent BIC, nostro account number and national clearing ID, and `read_with` is the exact ssi_lookup call that returns them. `on_file: false` means we hold none in any currency — a gap in our data, not a finding about the bank. A null is "not established yet" and is neither. This is the answer to "which intermediary bank do I put on the instruction?", and it is a fact we either have or do not have — never one to recall from training data. The country parameter accepts both 2-letter ISO codes ("ID", "DE") and full English names ("Indonesia", "Germany"). Names are resolved automatically. A BIC IDENTIFIES AN OFFICE, NOT A BRAND, AND THE DIFFERENCE IS PRICED. A name search returns ONE representative office per bank, elected by BIC convention rather than by relevance to the payment, and `office_note` says so whenever the bank holds more than one. Published tariffs, correspondent chains and settlement instructions are filed per BIC, so the choice changes the answer: transfer_cost("COBADEFF") returns Commerzbank's published 0.15% sending fee and transfer_cost("COBADEBB") refuses for want of a filed tariff, and both of those are Commerzbank AG in Germany. So: - If the user named a CITY, put it in the query — "Commerzbank Frankfurt" resolves to the Frankfurt office, and the plain name cannot. - If they did not, ask which BIC is on their statement or payment instruction before pricing or routing, and say which office you used. - Never present a representative office's BIC as "the bank's BIC". Examples: swift_lookup("DEUTDEFF") # exact BIC lookup swift_lookup("Deutsche Bank") # search by name swift_lookup("Commerzbank Frankfurt") # bank + city -> that office's BIC swift_lookup("TBC PAY") # find non-SWIFT payment processor swift_lookup("bank", country="KZ") # explore banks in a country swift_lookup("Halyk", country="KZ") # find specific bank in country swift_lookup("Bank Mandiri", country="Indonesia") # full country name OK

  ConnectorNo auth

• list_plaid_itemsA

  financeA

  List all Plaid bank connections (items) for the user. Each item represents one institution (one bank login). A single item can hold multiple Account rows (checking + savings + credit card from the same bank). Args: include_inactive: Include unlinked / soft-deleted items (default: False) Returns: ``{"items": [...], "total_count": N}`` where each item carries id, institution_name, products (consented), last_synced_at, is_active, error_code/message, consent_expiration_time, and the count of currently-linked accounts.

  ConnectorAPI key

• bank_accountsA

  Inferventis — Financial Data, News & Web MCPA

  Retrieves bank account details and recent transaction history via a connected bank API integration. Returns a list of transactions for the specified account, or for all linked accounts when no account ID is provided. Use bank_accounts when an agent needs to inspect account balances, review recent spending, categorise transactions, or reconcile records against a specific bank account. Prefer open_banking_transactions when the integration uses a PSD2 Open Banking provider (TrueLayer) covering 300+ UK and European banks — open_banking_transactions returns richer transaction metadata including merchant names, categories, and running balances. Prefer stripe_payments when the source of payments is a Stripe merchant account rather than a retail bank account. This tool requires a valid bank API credential to be configured on the server.

  ConnectorNo auth

• bank_accountsA

  Inferventis MCP ServerA

  Retrieves bank account details and recent transaction history via a connected bank API integration. Returns a list of transactions for the specified account, or for all linked accounts when no account ID is provided. Use bank_accounts when an agent needs to inspect account balances, review recent spending, categorise transactions, or reconcile records against a specific bank account. Prefer open_banking_transactions when the integration uses a PSD2 Open Banking provider (TrueLayer) covering 300+ UK and European banks — open_banking_transactions returns richer transaction metadata including merchant names, categories, and running balances. Prefer stripe_payments when the source of payments is a Stripe merchant account rather than a retail bank account. This tool requires a valid bank API credential to be configured on the server.

  ConnectorNo auth

• lookup_entityA

  factankerA

  Resolve a US company, bank or nonprofit to its registry entity. Use when you have a name, ticker context or an identifier and need the entity plus all known registry anchors (CIK, LEI, EIN, UEI, RSSD). IDs beat names — prefer 'cik:0000936468', 'lei:...', 'ein:...', 'uei:...', 'qid:Q7240'. This returns identity only, no figures — follow up with get_facts or get_timeseries using the returned entity id. Watch the level: a bank holding company (CIK) and its operating bank (RSSD) are different entities with different balance sheets.

  ConnectorNo auth

• list_expensesA

  stubA

  List the business's expenses with amount, date, category account, linked bank transaction and notes. These are recorded expense entries; for recorded income use list_income, and for raw bank-feed lines use list_transactions.

  ConnectorOAuth

• get_bank_profile_statusA

  stubA

  Report the business's bank-connection profile without pulling any transactions. Returns :providers (live Yodlee provider-link + per-dataset refresh health) AND :bankfeeds (per-provider connection status for every other linked bank feed — Capitec, GoCardless, Investec, Stripe and the other bank-connection apps — derived from stored install state, no live external call). A business with no Yodlee link still gets its :bankfeeds; only a business with no bank connection at all returns an explanatory :message, NOT an error.

  ConnectorOAuth

• reconcile_statementA

  VitafinB

  Reconcile one account against a bank statement for a period. Give the statement as CSV text or as rows (date, amount, description) you read off a PDF. Reports matched lines, lines the app is missing, ledger rows the bank never saw, and the closing-balance difference. Dry-run unless commit=true; then the missing rows are added as bank-confirmed, the unexplained ledger rows go to the review queue, and the run is recorded.

  Connector

  Destructive

  OAuth

• ifsc_lookupA

  Ifsc InA

  Indian bank branch lookup by IFSC code. Resolves an 11-character IFSC code (printed on Indian cheques and bank statements) to the bank name, branch, address, city, district, state, MICR code, SWIFT code, and contact number, plus whether the branch supports the NEFT, RTGS, UPI, and IMPS payment rails. India banking / fund-transfer routing data via the open Razorpay IFSC dataset (keyless). Also returns an offline format_valid check of the code structure. NOTE: this validates and resolves the IFSC code itself — it does NOT verify a bank account or account holder. Examples: ifsc_lookup({ ifsc: "HDFC0CAGSBK" }), ifsc_lookup({ ifsc: "sbin0000691" }) (case and spaces are forgiven).

  ConnectorNo auth

• worldbank.dev.indicatorsA

  apibaseB

  Search 16,000+ World Bank development indicators by keyword or topic — GDP, population, poverty, education, health, environment, trade. Returns indicator ID, name, source, description, topics. Use indicator IDs with finance.country_data for time-series data (World Bank, CC BY 4.0)

  ConnectorNo auth

• shinhan_easy__linked_accounts__listA

  XBOSSB

  No credential or login required. List the Shinhan Bank account links this caller registered, each with the account_link_id and bank_account_credential_id the accounts and transaction history tools need. Reads our records only; shinhan_easy.accounts.list fetches live accounts from the bank.

  ConnectorNo auth

• lei_hierarchy_treeA

  GleifA

  Walk the FULL corporate ownership hierarchy for an entity in one call: the ancestor chain from the entity up to its ultimate parent, plus a multi-level tree of subsidiaries below it (breadth-first over GLEIF Level 2 direct-child records, depth-limited, depth stated in the response). Accepts a 20-character LEI or a company NAME. Answers "everything this group ultimately controls" / "full subsidiary tree of Deutsche Bank" / "who is at the top of this entity's ownership chain" — use get_lei_relationships instead when one hop (direct parent + direct children) is enough.

  ConnectorNo auth

• get_poverty_regionalA

  Worldbank PovertyA

  Aggregated World Bank poverty estimates at the regional/group level (not per-country). Returns headcount, poverty gap, mean welfare, and total population in poverty for each group. group_by controls the aggregation: "wb" = World Bank geographic regions, "inc" = income groups (HIC/UMIC/LMIC/LIC), "none" = global total.

  ConnectorNo auth

• resolve_nubanA

  Mansa African Financial Reference DataA

  Work out which Nigerian banks a 10-digit NUBAN account number could belong to. The CBN check digit is computed from the bank code plus the first nine digits, so testing the number against every bank code narrows a shortlist without contacting any bank. Typically reduces ~30 banks to ~3. This confirms checksum validity only: it does NOT confirm the account exists, and it never returns the account holder's name, which requires a licensed NIBSS account-name enquiry.

  ConnectorNo auth

• bic_checkA

  x402 BazaarB

  Is this bank code even well-formed? — Validate a BIC/SWIFT code offline (ISO 9362): 8 or 11 characters, bank/country/location[/branch] layout, head-office vs branch, and the test-BIC flag. Every rejection names which check failed. Structure only — does not prove the bank is live. Required input: bic. Priced $0.002 per call over x402 on Base; send a prepaid x-credit-token header for unlimited calls, or get 1 free call/day per tool. No wallet or API key required.

  ConnectorNo auth

• get_nonresident_bankingA

  mcp-serverB

  BANK-ACCOUNT ACCESS for FOREIGN NON-RESIDENTS in a jurisdiction — two profiles: (a) non-resident individual, (b) foreign entity. Each carries the STATUTORY position AND the PRACTICAL bank appetite separately (many countries are legally open but practically closed — the two are never merged), plus typical KYC/document set, remote-opening availability, indicative minimums (bank policy, never law), timelines, CRS/FATCA notes and EDD triggers. Deepens the formation-linked banking landscape to 194-country coverage. Pass cc for one jurisdiction; omit for the covered list. Account opening is decided unilaterally by each bank — NO account opening is ever guaranteed; full CRS/FATCA transparency always. Information, not financial or legal advice.

  ConnectorNo auth

• mercury.transactionsA

  DPX — Institutional Cross-Border SettlementA

  List recent transactions for a Mercury bank account. Returns transaction ID, amount (USD), status, note/memo, counterparty name, created date, and whether the transaction was DPX-tagged (memo contains "dpx:"). Filter by account ID obtained from mercury.accounts. Use this to reconcile DPX settlements against Mercury bank activity.

  ConnectorNo auth