Format IDs and date-times

Use this page whenever a field is described as an ID, date, date-time, or timestamp. These rules prevent duplicate processing and avoid time-zone mistakes.

Build a message ID

GrpHdr.MsgId is a 35-digit value with three parts:

123456 20260816101530000 000000000001
------ ----------------- ------------
sender UTC timestamp     sequence
code   yyyyMMddHHmmssfff 12 digits

The complete value has no spaces or punctuation:

12345620260816101530000000000000001

Part	Length	Example	Meaning
Sender member code	6 digits	`123456`	Identifies the institution or service that created the message. Use the code issued by Blinc during onboarding. Do not create a code locally.
Creation timestamp	17 digits	`20260816101530000`	UTC year, month, day, hour, minute, second, and millisecond: `yyyyMMddHHmmssfff`.
Sequence	12 digits	`000000000001`	A zero-padded counter that prevents two messages created in the same millisecond from receiving the same ID.

Generate a new message ID for every new request and response. An institution response uses the institution member code, not the code copied from the request. Never reuse the request message ID as the response message ID.

When Blinc delivers the same Credit Notification, Credit Transfer, or Reverse again, the business identifiers stay unchanged. A new delivery timestamp does not authorise a second business action. Blinc does not retry Account Linking, Account Unlinking, or Debit Authorization; see Return clear errors and handle repeated deliveries.

Message-ID validation

Reject GrpHdr.MsgId when any of these checks fails:

It is not exactly 35 characters.
It contains anything other than digits 0 through 9.
The first six digits do not identify the expected sender.
The 17-digit timestamp is not a real UTC date and time.
The timestamp is in the future beyond the agreed clock-skew allowance or older than the agreed validity window.
The same ID was previously used for different plaintext.

Value	Result	Reason
`12345620260816101530000000000000001`	Valid	Correct code, timestamp, sequence, and length.
`123456-20260816101530000-000000000001`	Invalid	Separators are not allowed.
`12345620261316101530000000000000001`	Invalid	Month `13` is not real.
`1234562026081610153000001`	Invalid	The value is too short.

Treat business identifiers as opaque text

The IDs below are stable references, not mini-databases hidden inside strings:

account-linking request ID and account-linking ID;
instruction ID;
end-to-end ID;
transaction ID;
clearing-system reference;
client reference;
posting reference;
acceptance ID;
creditor, device, terminal, and merchant IDs.

Unless a field page states a stricter rule:

send a non-empty JSON string;
use printable characters and avoid leading or trailing spaces;
compare the complete value exactly, including letter case;
store the value without rewriting it;
do not extract dates, institution codes, or account details from it;
keep it unchanged when Blinc retries Credit Notification, Credit Transfer, or Reverse;
never reuse it for a different business action.

Prefixes such as DD-, REV-, or MANDATE- make test data easier to read, but they are examples, not required syntax.

Use each ID for its stated job

ID	Created by	What it identifies	Repeated-delivery rule
`GrpHdr.MsgId`	Sender of the message	One message	When Blinc is permitted to deliver the same operation again, a reused value must contain the same plaintext and resolve to the stored result. A new customer-started link or unlink request gets a new value.
`AccountLinking.account_linking_request_id`	Blinc	One request to create an account link	Blinc does not retry Account Linking. If the customer starts again, the new request gets a new value.
`AccountLinking.account_linking_id`	Issuing institution	The stored account-linking account link	Return it after linking and require it on later debit and unlink requests.
`PmtId.InstrId`	Blinc	One payment instruction	It stays unchanged when Blinc delivers Credit Notification, Credit Transfer, or Reverse again. For a timed-out debit, preserve the original debit references in the Reverse request; Blinc does not resend Debit Authorization.
`PmtId.EndToEndId`	Blinc	One payment across all participating systems	Preserve it in responses and use it to locate the original debit for a Reversal.
`PmtId.TxId`	Blinc	One transaction in the switching flow	Do not assign it to another transaction.
`PmtId.ClrSysRef`	Blinc	The clearing-system trace record	Preserve it for reconciliation and support searches.
`auth_binding.key_id`	Authenticator store	The active authenticator used for approval	Send it as a positive JSON integer, not quoted text. It is not a device ID or public key.

Format date-times in UTC

Use RFC 3339 / ISO 8601 UTC text with a trailing Z:

2026-08-16T10:15:30.123Z

The canonical pattern is:

yyyy-MM-dd'T'HH:mm:ss.fff'Z'

Part	Example	Meaning
`yyyy-MM-dd`	`2026-08-16`	Four-digit year, two-digit month, and two-digit day.
`T`	`T`	Separates the date from the time.
`HH:mm:ss`	`10:15:30`	24-hour UTC time. `10` means 10 a.m.; `22` means 10 p.m.
`.fff`	`.123`	Milliseconds. Send exactly three digits.
`Z`	`Z`	Says the value is UTC, not local time.

Do not send a local offset such as +01:00, a time-zone name such as WAT, a locale-specific date such as 16/08/2026, or a value without a time zone.

Value	Result	Reason
`2026-08-16T10:15:30.123Z`	Valid	Complete UTC date-time with milliseconds.
`2026-08-16T10:15:30Z`	Invalid	Milliseconds are missing from the canonical contract form.
`2026-08-16 10:15:30.123`	Invalid	Missing `T` and `Z`.
`16/08/2026 10:15`	Invalid	Ambiguous local format.

Understand the different time fields

Field	What the time describes	Relationship
`x-timestamp`	When this protected HTTP delivery was created	Used for replay protection. It can differ from the business message creation time.
`GrpHdr.CreDtTm`	When the readable business message was created	Must agree with the message-ID timestamp and be within the accepted window.
`IntrBkSttlmDt`	When inter-institution settlement applies	Send midnight UTC when the business rule supplies only a calendar date, for example `2026-08-16T00:00:00.000Z`.
`AuthntcnTmstmp`	When the customer approved a Debit Authorization	Must not be after the request creation time.
`BookgDt.Dt`	When an account entry was booked	Use the actual booking time or midnight UTC if the ledger exposes only a date.
`ValDt.Dt`	When funds begin to have value	May differ from booking time according to the institution's ledger rules.

Parse date-times before using them. Reject impossible dates, non-UTC values, and relationships that contradict the operation rules.

Learn the JSON shapes reused by the operations in Understand common payment fields.