Engine Config

The Engine Config page (/visa/engine-config or /mastercard/engine-config) is where you view and edit your organization’s engine configuration — the per-network settings CPS stores and publishes for the Visa Engine, the Mastercard Engine, and SMP. Not every field currently drives simulated processing; see The fields for what each one actually does today.

What engine configuration is

Switchbench runs a separate stateless engine per card network: the Visa Engine (switchbench_sve) and the Mastercard Engine (switchbench_sme). Neither engine has its own database. Instead, each polls the Control Plane Service (CPS) for every organization’s config document on its network and keeps the result in an in-memory snapshot, refreshed on a background interval (five minutes by default). Of the fields this page edits, only the acquiring/forwarding institution IDs currently have a real effect on processing today, and that effect comes from SMP, not from either engine — see The fields below for what each field actually does right now.

Per-network scoping

Visa and Mastercard config are independent documents. Each network has its own page in the sidebar, and the section you open pins that network. Setting a field for Visa has no effect on Mastercard, and vice versa; there is no shared or default config between the two engines. If your organization runs both networks, you configure each one separately. The old /engine-config URL redirects to the Visa page.

The fields

• Acquiring institution ID — ISO 8583 DE 32, the acquiring institution identification code. SVE and SME do not read this value when building outbound messages; SMP reads it from this same config document to cross-check the DE 32 it sees on inbound TCP traffic against what your organization has configured, as defense-in-depth alongside the mTLS client-certificate check.
• Forwarding institution ID — ISO 8583 DE 33, the forwarding institution identification code, used the same way as the acquiring institution ID above (SMP’s DE 33 cross-check, not engine processing).
• Default currency — a 3-letter ISO 4217 code. It is stored and published in the config document, but at present neither SVE nor SME applies it — setting this field does not change simulated processing on either network.
• Routing — a JSON object describing routing rules for this network. Required by CPS; use {} for none. (Individual routing rules, as opposed to this raw JSON document, are managed on their own page.) SVE parses this document into a routing table at load time, but nothing in SVE’s production code currently looks values up in it — the same as default_currency, it is stored and parsed but not yet applied to processing. SME does not even parse it.
• Currency (multicurrency) — an optional JSON object of multicurrency settings. Leave it blank to disable multicurrency handling for this network. SVE parses this into a multicurrency helper at load time, but nothing in SVE’s production code currently calls it to perform a conversion — again, stored and parsed but not yet applied. SME does not even parse it.

For how these fields surface on the wire, see Visa ISO 8583 and Mastercard ISO 8583.

How a change takes effect

Saving on this page writes immediately to CPS — there is no separate publish step, and no engine restart is required for any field.

For acquiring/forwarding institution ID — the only fields with a real processing effect today — the consumer is SMP, via its own separately-cached read of this config for the DE 32/33 cross-check (see The fields above), not SVE or SME.

Routing, currency, and default currency are stored and (for routing/currency on Visa) parsed by SVE into an in-memory snapshot refreshed from CPS on a background poll (five minutes by default), but as noted above nothing in production currently applies any of the three to a simulated transaction — so there is no processing effect to observe from saving them yet, on either network, regardless of poll timing.

Read-only access

Viewing this page needs engine:read; saving needs engine:config:write. If you only have read access, the form renders but every field is disabled — ask an administrator for engine:config:write to make changes.

Saving also needs the network’s product to be entitled. When the product has lapsed (no active trial or subscription), the page is read-only, and a save that gets through is refused with 403 (product_not_entitled). Products are covered in Products and trials.

Save before you switch networks in the sidebar. Moving from one network’s Engine Config section to another’s resets the form, and unsaved edits are lost without a prompt.

Concurrent edits

CPS tracks a version for each config document, and the page uses it for a best-effort conflict check: just before saving, it re-checks whether the version you loaded is still current, and shows a conflict banner instead of saving if it isn’t. This narrows the window for silently overwriting someone else’s change, but doesn’t close it — CPS itself doesn’t enforce the version on write, so a save that lands in the brief gap between that check and your own write can still be overwritten. If you’re coordinating a change with someone else, confirm out of band that you’re not both editing the same network’s config at the same time, rather than relying on the banner alone.