MyBankMatch

Prepare the connection

1. Have an active license with the MY_BANK_MATCH product and available quota.
2. Open Clients · MyBankMatch with your authenticated session and the corresponding license.
3. Click Connect bank and complete authentication in the Wealthreader-hosted window. The tokenized connection is associated with your api_key; the bank token is not delivered to the browser and is not a query parameter.
4. Refresh the status in Clients. If the bank requires you to authenticate again, use Reconnect. The panel also offers an explicit IBAN/name test and the latest masked queries.

The issuer uses a single-use signed link and a browser-bound continuation. If the link has expired or loses that continuation, request another one from Clients.

Send a query from the backend

POST https://api.wealthreader.com/my-bank-match/
Content-Type: application/x-www-form-urlencoded

No JSON is sent and X-API-Key is not used: the key is part of the form-encoded body, just as in /entities/.

curl --request POST 'https://api.wealthreader.com/my-bank-match/' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'api_key=<SU_API_KEY>' \
  --data-urlencode 'iban=ES9321005707250200257112' \
  --data-urlencode 'name=Wealthreader S.L.'

<SU_API_KEY> is a placeholder, not a usable key. The IBAN and name illustrate the acceptance request; it has not been verified here that they produce a specific verdict. The query may be billable: do not send it as an automatic interface refresh.

MyBankMatch returns the bank's verdict. It does not replace that response with a local name-similarity calculation. Nor does it create, authorize or execute a payment order.

Interpret the response

HTTP 200 indicates that a product result has been obtained, not that the name necessarily matches. Check success and then payload.result.

Illustrative example of a partial match (simulated name and SESSION):

{
  "success": true,
  "payload": {
    "result": "PARTIAL_MATCH",
    "suggested_name": "TITULAR DE EJEMPLO S.L."
  },
  "statistics": {
    "SESSION": "0000000000000000",
    "execution_time": 0.42,
    "warnings": []
  }
}

statistics.SESSION identifies this query for diagnostics and execution_time is expressed in seconds. A successful response does not include an error object and does not return the bank connection token.

For a partial match, display the entered name and suggested_name separately; do not silently replace the former. If you render them in HTML, escape them as text.

The setup URL for NOT_CONFIGURED and REAUTH_REQUIRED is:

https://www.wealthreader.com/clients/#my-bank-match

For example, a reauthentication may return this payload:

{
  "result": "REAUTH_REQUIRED",
  "setup_url": "https://www.wealthreader.com/clients/#my-bank-match",
  "reason_code": 2000
}

reason_code must be an integer between 2000 and 2999; for example, 2000 corresponds to a credentials failure. Reconnect from Clients instead of repeating the verification indefinitely.

NOT_POSSIBLE may be due to temporary unavailability, an invalid bank response, the lack of a usable payer IBAN or an unavailable adapter. Keep reason for diagnostics, but do not turn these cases into a confirmation of ownership or a negative match.

Validation, quota and errors

Validation or license errors follow the usual envelope: success: false, payload, error.code, error.message and statistics with SESSION, duration and warnings. Controlled validations respond with HTTP 400; the message may include diagnostic information and must not be used as a stable identifier.

Input errors and inconclusive results do not consume the billable query quota. The quota is consumed when the bank returns MATCH, PARTIAL_MATCH or NO_MATCH; if another call exhausts it concurrently, the limit error is returned instead of confirming the result as successful.

The price of 0.10 EUR applies only to the three conclusive results of the contract. Per-query billing and the exclusion of verified linking sessions are implemented, but they require the prior schema and the activation/review of the billing queries by an operator; this page does not attest to that deployment. Only a verified server-side association allows a session to be excluded from the standard credentials/products calculation: a browser operation_id is not enough. Expired, unaudited or historical attempts without that provenance have no automatic exemption, and no other free counter effects are guaranteed.

Limits of this version

• Verification uses the client's own tokenized connection with Santander personal banking. Real bank compatibility has not been validated yet, and publishing this page does not guarantee commercial availability.
• The hosted flow supports credentials and OTP/push challenges, method selection and bounded raster QR. Script, OAuth, CAPTCHA or multi-contract challenges are not implemented and produce a safe error; you can request a new link from Clients.
• The panel requires an authenticated session. Loading the status, returning from the bank window and refreshing the history do not send verifications to the bank: only the explicit submission of the form performs a potentially billable query.
• Keep the api_key on your server and do not record credentials, bank tokens or full names in unnecessary integration logs. Use SESSION for support and respect the distinction between verdict, error and configuration status.