0800 / 0810 Network Management Messages: Sign-On, Echo Test and Key Exchange

One MTI, no money

Read 0800 digit by digit — the MTI decoder does it for you: version 0 (ISO 8583:1987), class 8 (network management), function 0 (request). 0810 is the same message with function 1: the response. Who originates is defined by your interface — typically the connecting party sends 0800 and the host answers, but both directions can be live on one link.

The body is tiny. A typical 0800 carries a timestamp (DE 7), a trace number (DE 11), the network management information code (DE 70), and — spec permitting — institution identifiers (DE 32/33) or key material. The 0810 echoes DE 7 and DE 11 and adds DE 39, the response code. No PAN, no amount, no merchant: class 8 is the only message class on the link where nothing financial is at stake.

DE 70 is the real operation code

Here is the part that trips up newcomers: the MTI tells you almost nothing. Every network management request is 0800 — sign-on, sign-off, heartbeat, key change and cutover all share it. The operation lives in DE 70, the three-digit Network Management Information Code (NMIC). Treat 0800 as the envelope and DE 70 as the verb: when someone says "we received an 0800", the first question is always "with what DE 70?".

A worked example you can paste into the parser

Here is a complete, well-formed sign-on request, written as ASCII text:

0800 8220000000000000 0400000000000000 0809083000 000001 001

Two things are worth noticing. First, the bitmap is almost empty — three data elements — which makes 0800 the cleanest message for learning to read bitmaps by hand (rebuild it in the bitmap calculator). Second, DE 70 sits at position 70, above 64 — so every network management message drags in a secondary bitmap for one lonely field. That is why bit 1 of the primary bitmap is set and the bitmap runs 32 hex characters instead of 16. Paste the whole line into the main parser and exactly these four fields come out.

The matching response adds one field, DE 39 — which flips bit 39 on in the primary bitmap (8220000002000000):

0810 8220000002000000 0400000000000000 0809083000 000001 00 001

DE 39 = 00 means the sign-on was accepted. Anything else is a rejection, and the code tells you why — the DE39 lookup covers the common values.

Heartbeats: interval, timeout, and where a failure lands you

Why heartbeat at all? Because an idle TCP connection lies. Firewalls and NAT boxes silently drop idle mappings, and a half-open socket looks healthy to the side that didn't notice — until a real authorization sails into the void. The echo test makes the link fail early and observably instead of at the worst possible moment.

The working rules on most links:

• Interval. Typically every 30 seconds to a few minutes, usually idle-triggered: real traffic proves liveness by itself, so echoes are skipped while transactions flow. Stay well under the idle-teardown timeout of every middlebox on the path.
• Timeout. An echo is judged like any other request: a matching 0810 (same DE 11) within T seconds — commonly the same 15–30 s timer used for transactions. One miss is a miss, not yet a death.
• Failure. After K consecutive misses (2–3 is typical), stop pretending: close the socket yourself, back off, reconnect.
• After reconnect, sign on again. The safe default is that sign-on state belongs to the connection: new socket, new sign-on. Some hosts track sign-on per institution and survive a reconnect — but an unverified "signed on" is exactly the assumption heartbeats exist to kill. If the spec is silent, re-sign-on: a redundant sign-on is harmless, a missing one rejects every transaction.

Note the self-loop for cutover: a business-date roll happens inside Ready. Nothing disconnects, nothing re-signs-on — only the settlement boundary moves.

STAN: yes, echo tests take numbers too

Network management messages occupy the same DE 11 space as everything else, and a response is matched to its request by DE 11 (plus DE 7) on the same connection. That makes STAN discipline a day-one problem: the heartbeat sender is often a different component from the transaction sender, and if the two share a sequence without coordination — or each restarts from 000001 — you get duplicates inside the matching window. The symptom is maddening: "the 0810 came back but matches no outstanding request", or worse, an echo response matched to a transaction. The fixes are boring and absolute: one allocator per connection, a counter that survives restarts, no reuse while a request bearing that STAN is outstanding. The full story of which numbers identify what is in STAN vs RRN.

When it goes wrong: a debugging checklist

You send 0800 and nothing comes back. Work up the stack. Is the TCP connection actually established, or half-open? Is the length header right — 2-byte binary vs 4-digit ASCII, inclusive or exclusive of itself? A wrong length prefix leaves the host waiting forever for bytes it thinks are still coming. Then encoding: ASCII where the host expects EBCDIC or BCD shifts every boundary. Most hosts silently drop messages they can't frame — capture the raw bytes and count them against your own length prefix before blaming the far end.

An 0810 arrives, but DE 39 isn't success. Good news: framing, encoding and connectivity are proven; what's left is content. 30 (format error) points at a field the host didn't like; institution-ID mismatches in DE 32/33 are the classic sign-on rejection; "not signed on" in answer to an echo means you skipped a step. Look the code up in the DE39 lookup, remembering network management responses often use a spec-specific subset of the table.

Heartbeats are green but transactions time out. The most instructive failure. An echo proves the socket and the far-end front-end — nothing more. Authorizations travel further: through routing, into an authorization host, sometimes out to an issuer. Green echoes plus dead transactions means the problem lives beyond the component answering your echoes — a down host behind the gateway, a routing table missing your BIN range, a sign-on whose scope doesn't cover the transaction service — or your 0200s are malformed in a way your 0800s aren't, since they exercise far more fields. Either way, stop staring at the link layer; the link is fine.

Read next

• STAN vs RRN: What's the Difference? — the numbers that match responses to requests
• Reading ISO 8583: MTI, Bitmaps & Fields — the three-layer anatomy behind every example above
• ISO 8583 DE39 Response Codes: Full Reference
• Reversals, Timeouts & Repeats: The ISO 8583 Failure Paths — what timeouts mean once money is involved