Schemas

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

The last four digits of the card, which pick which of the customer's cards is activated. Matched against the end of the masked card number rather than a stored field of its own, and no length is checked: a shorter value matches more than one card and the operation refuses rather than choosing, while anything longer than the masked number matches nothing.

The delivery barcode the consignment is tracked by.

Not read by the service. activateNoNameCard matches the card on customerNumber and lastFourDigit alone — the facade forwards this field and ActivateNoNameCard does not mention it, on credit, debit or prepaid. It is accepted and ignored.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Which group of products this one belongs to.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The caller's own identifier for this request, stored against the application so the two can be reconciled later. The platform does not interpret it.

The card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.

Why the application is being cancelled.

Free text alongside the cancellation reason.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Whether the card draws against the customer's limit rather than having one of its own.

Which profile the card's limits come from.

The description of profileCode, carried alongside it for display. It is not a key: match on the code.

Which limit row this is: the transaction group, the network and the channel together identify one. The descriptions beside each code are returned for display and are not part of the key.

The most the card may spend in one transaction.

The same cap as a share of the card's limit rather than an amount.

The most transactions the card may make in a day.

The most the card may spend in a day.

The most transactions the card may make in a week.

The most the card may spend in a week.

The most transactions the card may make in a month.

The most the card may spend in a month.

The most transactions the card may make in a year.

The most the card may spend in a year.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The card to change and replace. Checked here, in the first of two validation passes.

How the replacement is to be made. Checked in two passes: this field's presence first, and only then the embossing reason and sub-reason inside it. So a request that is missing both this and an embossing reason is refused for this one alone, and the second refusal only appears once this is sent.

Required in practice — The status to move the card to before it is replaced. Not checked in either pass — the status change is the first of the two service calls and refuses it there.

Values:

• A — valid
• B — pending
• C — stolen
• D — cancelled by the bank
• F — fraud
• G — temporarily blocked
• I — cancelled
• L — lost
• M — cancelled by the customer
• T — corporate dummy

Why the status is being set. The valid reasons depend on the status: getAvailableCardStatusList returns the pairs a card may move to.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

Whether the card ends this operation in an active status.

What the replacement produced.

Why the card is being replaced. It decides what the replacement inherits and whether the card number changes.

What the card may do: e-commerce, international purchases and mail order. Each is optional, and one left unset takes the platform's own default rather than being refused — for e-commerce that default follows digitalCardFlag.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Values:

• A — valid
• B — pending
• C — stolen
• D — cancelled by the bank
• F — fraud
• G — temporarily blocked
• I — cancelled
• L — lost
• M — cancelled by the customer
• T — corporate dummy

Why the status is being set. The valid reasons depend on the status: getAvailableCardStatusList returns the pairs a card may move to.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

What the replacement card should carry — delivery, address and emboss details. Left out, the replacement inherits the card's own.

Whether the card ends this operation in an active status.

The card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Whether the change produced a new card.

Whether the change moved the card to another product.

The card number with its middle digits masked, as the platform stores it. It is a display form, not a key.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Checked against the platform's Pin parameter rather than a fixed length, so it follows the tenant's configuration and can change without a release.

Checked against the platform's Pin parameter rather than a fixed length, so it follows the tenant's configuration and can change without a release.

The PIN block as the key management service produced it. The PIN itself never travels.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Required in practice — The card whose status changes. Not validated here — the facade forwards every field untouched, so an absent or unknown value is refused by the prepaid lifecycle service in its own vocabulary rather than as a missing field.

Required in practice — The status to move the card to. The transition itself is checked behind this API, against the channel group and the platform's transition matrix; sending the status the card already holds is refused rather than treated as a no-op.

Values:

• A — valid
• B — pending
• C — stolen
• D — cancelled by the bank
• F — fraud
• G — temporarily blocked
• I — cancelled
• L — lost
• M — cancelled by the customer
• T — corporate dummy

Required in practice — Why the status changes. It is checked as a pair with cardStatusCode — a reason that does not belong to the status is refused.

Conditional — When a closure was requested. Forwarded untouched; it is read by the closing transitions rather than by every status change.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

Whether the card ends this operation in an active status.

The branch the card is opened at, as a number. Held as a number rather than text throughout.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Not the channel every request carries: one of the differently-named channel fields the platform uses for other purposes.

Not the channel every request carries: this is one of nineteen differently-named channel fields the platform uses for other purposes, and no column behind this API stores it.

The identifier of the row the operation created or acted on, returned so a later call can name it.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

The branch the card is opened at, as a number. Held as a number rather than text throughout.

Not the channel every request carries: one of the differently-named channel fields the platform uses for other purposes.

Not the channel every request carries: this is one of nineteen differently-named channel fields the platform uses for other purposes, and no column behind this API stores it.

The identifier of the row the operation created or acted on, returned so a later call can name it.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Optional — Not read by the service. The facade's mapping of this field is commented out, so what is sent never leaves this API. setRsaPin and verifyRsaPin both forward their own operationDate; this one is the exception, and the field is published on all three.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

Required in practice — The card the operation acts on, by its shadow card number — the platform's own reference, not the PAN. Not validated here; an absent or unknown value is refused by the prepaid PIN service in its own vocabulary.

Required in practice — The current PIN, as an encrypted block. Not validated here; the prepaid PIN service verifies it before the change is made, so a change is a verification and a set in one call.

Its size follows the block format and the key it was built with rather than a column.

Required in practice — The encrypted PIN block. Not validated here — the facade forwards it to the prepaid PIN service, which is where the block is decrypted and the rules are applied. Neither this API nor that service is given a clear PIN on this path.

Its size follows the block format and the key it was built with rather than a column.

Whether the operation did what it was asked to. A false here arrives with HTTP 200, so it has to be read rather than inferred from the status.

The PIN block as the key management service produced it. The PIN itself never travels.

Whether the card may be used online.

Whether the card may be used for mail and telephone order.

Not read by the service. The facade maps eCommercePermitted and mailOrderPermitted onto the replacement and leaves this field out of the mapping entirely, so what is sent never reaches the lifecycle service and the new card's international permission is whatever the platform's own default makes it. savePrepaidCardPermission is where this permission can actually be set.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.

The caller's own identifier for this request, stored against the application so the two can be reconciled later. The platform does not interpret it.

Default — Defaults to 0, and 0 issues the card without a customer. A negative number is refused.

The delivery barcode the consignment is tracked by.

What the card may do: e-commerce, international purchases and mail order. Each is optional, and one left unset takes the platform's own default rather than being refused — for e-commerce that default follows digitalCardFlag.

The card number with its middle digits masked, as the platform stores it. It is a display form, not a key.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

The card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.

What the operation wants to say about work it did anyway. A warning does not mean the operation failed.

The card number, expiry and verification value, returned only where the operation and the channel are entitled to them.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The product to issue on. Leaving it out does not fail — it chooses. The facade reads the products applicable to the customer and takes the first one in that list, logging what it picked; which product is first is the platform's ordering, not a preference this API exposes. A customer with no applicable product is refused.

Sent, it must be a product the platform defines.

Default — Defaults to 0, and 0 issues the card without a customer: the service skips the customer lookup. The customer the card belongs to. It is also what the automatic product choice above is made against.

The main customer of a corporate relationship, as a number. The employees and supplementary holders under it carry their own customerNumber.

The card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.

Default — Defaults to 0. The branch the card is opened at. It is not checked against the branch list.

Values:

• P — by post
• S — to the branch

Not set is "".

Values:

• RA — home
• AL — business
• EA — employer
• OO — alternative
• WA — previous
• SW — SWIFT
• SS — SWIFT name and address
• MR — Mernis, registered
• MS — Mernis, stated

Not set is --.

The branch the card is delivered to.

Whether to enrol the new card with Masterpass. Forwarded to the issuing service, which does the enrolment; the card is created either way.

What the card may do: e-commerce, international purchases and mail order. Each is optional, and one left unset takes the platform's own default rather than being refused — for e-commerce that default follows digitalCardFlag.

Which cardholder contract the customer accepted. The pair with contractVersionNumber records what was agreed to and when.

Which version of that contract the customer accepted.

The name embossed on the card. The services truncate to 26 characters before writing rather than refusing a longer one, so a name that matters should be checked at 26.

A stored address to send the card to. The facade turns it into a single card-address entry of the send type; omitted, no address list is sent at all and the delivery fields alone decide.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

The contract record in the application system that this card comes from.

The identifier of the row the operation created or acted on, returned so a later call can name it.

The card number with its middle digits masked, as the platform stores it. It is a display form, not a key.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

The card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.

What the operation wants to say about work it did anyway. A warning does not mean the operation failed.

The card number, expiry and verification value, returned only where the operation and the channel are entitled to them.

The card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.

Default false — Whether the new card may be used for e-commerce. Omitting the whole permissions object sets this to false rather than leaving it to a platform default: the facade reads the field with a false fallback.

Not read by the service, and not the default either. The facade sends mail order as true unconditionally on this operation, whatever this field says and whether or not permissions was sent at all. A new prepaid card is mail-order permitted; use savePrepaidCardPermission afterwards to change it.

Not read by the service. The facade's permission mapping on this operation carries e-commerce and mail order and leaves this field out, so what is sent never reaches the issuing service. savePrepaidCardPermission is where it can be set.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The card product the card is issued on. Defined in the parameter tables; getCardProductList returns the ones a tenant may use.

Default — Defaults to false. Read only when productNumber is absent, to pick a digital or a physical no-name product; once the product is known the facade overwrites it from the product's card form.

Default — Defaults to 0, and 0 creates the application without a customer. A negative number is refused.

The branch the card is opened at, as a number. Held as a number rather than text throughout.

What the card may do: e-commerce, international purchases and mail order. Each is optional, and one left unset takes the platform's own default rather than being refused — for e-commerce that default follows digitalCardFlag.

The caller's own identifier for this request, stored against the application so the two can be reconciled later. The platform does not interpret it.

Default — Defaults to false. Whether to enrol the new card with Masterpass; the card is created either way.

The contract record in the application system that this card comes from.

The card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

Whether the card is a digital one.

The main customer of a corporate relationship, as a number. The employees and supplementary holders under it carry their own customerNumber.

Whether this is a supplementary card rather than a main one.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

Values:

• A — valid
• B — pending
• C — stolen
• D — cancelled by the bank
• F — fraud
• G — temporarily blocked
• I — cancelled
• L — lost
• M — cancelled by the customer
• T — corporate dummy

Why the status is being set. The valid reasons depend on the status: getAvailableCardStatusList returns the pairs a card may move to.

The card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.

The card number with its middle digits masked, as the platform stores it. It is a display form, not a key.

The card product the card is issued on. Defined in the parameter tables; getCardProductList returns the ones a tenant may use.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The description of statementPeriod, carried alongside it for display. It is not a key: match on the code.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

Whether the card draws against the customer's limit rather than having one of its own.

Which profile the card's limits come from.

The description of profileCode, carried alongside it for display. It is not a key: match on the code.

Which limit row this is: the transaction group, the network and the channel together identify one. The descriptions beside each code are returned for display and are not part of the key.

The most the card may spend in one transaction.

The same cap as a share of the card's limit rather than an amount.

The most transactions the card may make in a day.

The most the card may spend in a day.

The most transactions the card may make in a week.

The most the card may spend in a week.

The most transactions the card may make in a month.

The most the card may spend in a month.

The most transactions the card may make in a year.

The most the card may spend in a year.

Which kind of card, as the one-letter code the account type carries: C credit, D debit, P prepaid.

The platform's identifier for this call, for tracing it in the logs.

The platform's own code for the error, and what to match on.

The error in words. errorCode is the part to match on; this is for a log or a screen.

The error in words. errorCode is the part to match on.

The message before its arguments were substituted in, which is what groups two errors that differ only by their values.

The values substituted into messageFormat.

Which field of the request the error is about.

More about the error than message carries, where there is more.

The individual problems, where one error stands for several.

Whether the failure is the platform's rather than the request's. A technical error is worth retrying; a business one is not.

The platform's internal exception class. Useful in a support conversation and not something to match on.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Required in practice — The card the operation acts on, by its shadow card number — the platform's own reference, not the PAN. Not validated here; an absent or unknown value is refused by the prepaid PIN service in its own vocabulary.

The error in words, for a log or a screen rather than for matching.

The card verification value. Computed and compared rather than stored, and returned only where the operation is entitled to it.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

The main customer of a corporate relationship, as a number. The employees and supplementary holders under it carry their own customerNumber.

Which rows to return. Left out, the operation returns them all.

The products the search matched.

Whether the product can be issued as a digital card.

Whether this is a supplementary card rather than a main one.

The card product the card is issued on. Defined in the parameter tables; getCardProductList returns the ones a tenant may use.

The card product's full name.

The card product's short name, for a list or a statement line.

Which scheme the card is issued on.

The annual fee the product carries.

Whether the clearing record was matched to an authorisation.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

The merchant category code — the four-digit code the scheme classifies the merchant's trade with.

The downstream system's own result code, passed through. 00 and 0 are success; anything else is its refusal, and responseReasonCode or the description says which.

Why the downstream system answered as it did, where it narrows the response code.

The retrieval reference number — the card scheme's handle for the transaction, and what a bank quotes when asking the scheme about it.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Which row of the transaction-code matrix this transaction was classified by.

Where the transaction has got to.

The search itself. The request body carries a single object, named after the query behind it, and its fields are the criteria.

Whether the clearing record was matched to an authorisation.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

Which chip on the card was used, where a customer holds more than one card on the same number.

Which channel the row applies to.

The description of ChannelType, carried alongside it for display. It is not a key: match on the code.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

What the transaction earned.

Whether the card's chip was used rather than the stripe.

The amount converted into the bank's own currency.

The bank's own currency, which localAmount is in.

The description of LocalCurrencyCode, carried alongside it for display. It is not a key: match on the code.

The card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.

The main customer of a corporate relationship, as a number. The employees and supplementary holders under it carry their own customerNumber.

The card number with its middle digits masked, as the platform stores it. It is a display form, not a key.

That matching state in words.

The merchant category code — the four-digit code the scheme classifies the merchant's trade with.

The description of Mcc, carried alongside it for display. It is not a key: match on the code.

Which group of merchant categories the merchant falls in.

Where the merchant is, as a country code.

The merchant's name as it reached the platform from the scheme.

Whether the terminal approved the transaction without asking the issuer.

How the card was read at the terminal — chip, stripe, contactless, keyed, or stored on file. The scheme's own code.

Whether the transaction was authorised with a PIN.

Whether the product can be issued digitally.

The card product's full name.

Whether the product is a virtual one.

The retrieval reference number — the card scheme's handle for the transaction, and what a bank quotes when asking the scheme about it.

The amount as it settles between the scheme and the bank.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

What kind of terminal that was — POS, ATM, or another.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

The transaction in words, as it reached the platform.

The amount of the transaction, in its own currency.

The description of TrnCodeMatrixId, carried alongside it for display. It is not a key: match on the code.

Which row of the transaction-code matrix this transaction was classified by.

The currency the transaction was made in.

The description of TrnCurrencyCode, carried alongside it for display. It is not a key: match on the code.

Whether the transaction adds to the balance or takes from it.

Whether the transaction can earn a reward.

The transaction's state in words.

The unique transaction identifier the platform gives a transaction, and the handle every later operation on it takes. Returned by the transaction listings.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Optional · Default false — Return every card under the corporate hierarchy. True discards customerNumber: the facade clears it before the read, so a request carrying both does not narrow to that customer. mainCustomerNumber is what scopes a corporate listing.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

The main customer of a corporate relationship, as a number. The employees and supplementary holders under it carry their own customerNumber.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The delivery barcode the consignment is tracked by.

A PAN to find the card by. It is resolved to a shadow card number before anything else runs, and a PAN that matches no card is refused with 20008 rather than returning an empty list — the one input here that fails rather than filters.

Narrows the listing by the cards' purpose. It is not a criterion on its own: see the 200 description — a request carrying only this field answers with an empty list.

The branch the card is opened at, as a number. Held as a number rather than text throughout.

Matches part of the cardholder's name, against the normalised search copy of it rather than the name on the card: uppercased, accents folded, and matched as a fragment.

Matches the customer's tax number or national identity number. The query compares the first ten characters of one and the first eleven of the other, so a longer value finds nothing rather than being refused.

Narrows the listing by where the card is in delivery. One of the eight fields that counts as a criterion.

The cards the search matched.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

The limit rows to set.

Which limit row this is: the transaction group, the network and the channel together identify one. The descriptions beside each code are returned for display and are not part of the key.

The most the card may spend in one transaction.

The same cap as a share of the card's limit rather than an amount.

The most transactions the card may make in a day.

The most the card may spend in a day.

The most transactions the card may make in a week.

The most the card may spend in a week.

The most transactions the card may make in a month.

The most the card may spend in a month.

The most transactions the card may make in a year.

The most the card may spend in a year.

Which channel the row applies to.

When the row was created.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

The description of operationResult, carried alongside it for display. It is not a key: match on the code.

The description of operationType, carried alongside it for display. It is not a key: match on the code.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The bank identification number — the leading digits of the card number that name the issuer and the product range.

Which kind of card, as the one-letter code the account type carries: C credit, D debit, P prepaid. — 0 None, 1 Credit, 2 Debit, 3 Prepaid

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

Narrows the list by what the cards are wanted for. One letter, compared in the query itself; anything that is not one of the five below filters nothing rather than being refused.

• B — cards in a valid status
• C — open cards, status A
• D — usable cards, and cards in status G
• E — closed cards other than G
• F — cards that may be reissued

The cards the search matched.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

The limit rows to set.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The unique transaction identifier the platform gives a transaction, and the handle every later operation on it takes. Returned by the transaction listings.

The unique transaction identifier the platform gives a transaction, and the handle every later operation on it takes. Returned by the transaction listings.

The transaction this one refers to — the original, for a reversal or a correction.

Which row of the transaction-code matrix this transaction was classified by.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

The card number with its middle digits masked, as the platform stores it. It is a display form, not a key.

The amount of the transaction, in its own currency.

The currency the transaction was made in.

The downstream system's own result code, passed through. 00 and 0 are success; anything else is its refusal, and responseReasonCode or the description says which.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

Where the transaction has got to.

The system trace audit number — the scheme's sequence number for the message, unique within a day and a terminal.

The retrieval reference number — the card scheme's handle for the transaction, and what a bank quotes when asking the scheme about it.

The authorisation code the issuer returned when the transaction was approved. Six characters, from the scheme.

The terminal the transaction was made at.

The merchant's number with the acquirer.

The merchant's name as it reached the platform from the scheme.

How the card was read at the terminal — chip, stripe, contactless, keyed, or stored on file. The scheme's own code.

Which chip on the card was used, where a customer holds more than one card on the same number.

The merchant's address as it reached the platform.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

The name embossed on the card.

The upper bound on the transaction amount.

The lower bound on the transaction amount.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Which network the transaction arrived over.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

Which row of the transaction-code matrix this transaction was classified by.

The search itself. The request body carries a single object, named after the query behind it, and its fields are the criteria.

The authorisation code the issuer returned when the transaction was approved. Six characters, from the scheme.

The merchant's identifier at BKM, the domestic switch.

Which channel the row applies to.

The description of ChannelType, carried alongside it for display. It is not a key: match on the code.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

The name embossed on the card.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

The amount converted into the bank's own currency.

The bank's own currency, which localAmount is in.

The card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.

The main customer of a corporate relationship, as a number. The employees and supplementary holders under it carry their own customerNumber.

The card number with its middle digits masked, as the platform stores it. It is a display form, not a key.

The merchant category code — the four-digit code the scheme classifies the merchant's trade with.

The description of Mcc, carried alongside it for display. It is not a key: match on the code.

Which group of merchant categories the merchant falls in.

Where the merchant is, as a country code.

The merchant's name as it reached the platform from the scheme.

The network's name, for display.

Whether the terminal approved the transaction without asking the issuer.

How the card was read at the terminal — chip, stripe, contactless, keyed, or stored on file. The scheme's own code.

Whether the product can be issued digitally.

Whether the product is a virtual one.

The transaction this one refers to — the original, for a reversal or a correction.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

The amount as it settles between the scheme and the bank.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The terminal the transaction was made at.

What kind of terminal that was — POS, ATM, or another.

The transaction in words, as it reached the platform.

The amount of the transaction, in its own currency.

The description of TrnCodeMatrixId, carried alongside it for display. It is not a key: match on the code.

Which row of the transaction-code matrix this transaction was classified by.

The currency the transaction was made in.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

The transaction in words, as it reached the platform.

Whether the transaction adds to the balance or takes from it.

Whether the transaction can earn a reward.

The unique transaction identifier the platform gives a transaction, and the handle every later operation on it takes. Returned by the transaction listings.

The branch the card is opened at, as a number. Held as a number rather than text throughout.

Held as a number rather than text, so a character limit would say nothing about it.

The customers to act on, by their object identifiers.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

One-of — The card to read. Send this or cardNumber; sending neither is refused, naming both.

One-of — The card's PAN. Resolved to a shadow card number first and refused if it matches none. When both are sent, this one is resolved and overwrites the other.

The card the operation is answering about.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The unique transaction identifier the platform gives a transaction, and the handle every later operation on it takes. Returned by the transaction listings.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The downstream system's own result code, passed through. 00 and 0 are success; anything else is its refusal, and responseReasonCode or the description says which.

Comes back from the transaction services; no column behind this API holds it.

Why the downstream system answered as it did, where it narrows the response code.

Comes back from the transaction services; no column behind this API holds it.

Resolved by the transaction services. A column of this name exists on the operation limit tables, which this operation does not read, so its five characters are not published here.

Values:

• O — on-us
• D — domestic, through BKM
• M — Mastercard
• V — Visa

Which row of the transaction-code matrix this transaction was classified by.

Resolved by the transaction services. A column of this name exists on the digital receipt tables, which this operation does not read.

The upper bound on the transaction amount.

The lower bound on the transaction amount.

The amount of every entry in the list added together.

The transactions the search matched.

Whether the product is a virtual one.

Whether the product can be issued digitally.

The terminal the transaction was made at.

The authorisation code the issuer returned when the transaction was approved. Six characters, from the scheme.

Whether the clearing record was matched to an authorisation.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

Which chip on the card was used, where a customer holds more than one card on the same number.

The description of channelType, carried alongside it for display. It is not a key: match on the code.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

Whether the card's chip was used rather than the stripe.

The amount converted into the bank's own currency.

The description of localCurrencyCode, carried alongside it for display. It is not a key: match on the code.