Understanding Transaction Date and Time

Varied Silvergate accounts will show transaction records in API history responses from a variety of payment channels, some with their own native time zones. We also recognize that our customers are performing transaction attribution from around the globe. To assist, this document
is meant to exhaustively communicate important format and time zone details for fields contained in our API responses.

Formats and Timezones

For all fields in endpoint Responses and Params labeled date-time, the format is RFC 3339, which has the format of YYYY-MM-DD HH:MM:SS.mm. For example, "2022-08-29 20:10:46.864".

Some fields do not populate a time but will still adhere to the format. For instance, fields like effective_date in GET history could show, "2022-08-10T00:00:00", where there is no time component. However a date will always be relative to a time zone; and for fields like effective_date the date will always be a banking day, specifically based on Silvergate's headquarters in Pacific Time. In other words, the end of one day and the beginning of the next in fields with no time component still relies on a time zone.

A final important callout: When tying together wire data from GET history and GET payments, a payment could show up in a different date range for GET history than for GET payments. This is because GET history is querying when a payment posts to an account, whereas GET payments is querying the date when an inbound payment arrived at Silvergate or an outbound payment was initiated (the entry_date).

Date-Time Field Compilation by Endpoint:

  • ACCOUNT

    • GET Balance

      • account_opened_date

        • The date on which the account was opened

        • timezone: Pacific

        • format: YYYY-MM-DDT00:00:00 (ISO 8601 with time always zeroed out)

      • last_statement_date

        • The date of the most recent statement

        • timezone: Pacific

        • format: YYYY-MM-DDT00:00:00 (ISO 8601 with time always zeroed out)

    • GET cash manager account balance

      • opened_date

        • The date on which the account was opened

        • timezone: Pacific

        • format: YYYY-MM-DDT00:00:00 (ISO 8601 with time always zeroed out)

    • GET History

      • begin_date

        • Optional, the beginning date range for history query; a blank value will default to current day. Note- date fields ignored when is-real-time=true. This parameter is querying effective_date

        • timezone: Pacific

      • end_date

        • Optional, the ending date range for the history query; a blank value will default to current day. Note- date fields ignored when is-real-time = true. This parameter is querying effective_date

        • timezone: Pacific

      • transaction_description

        • String, the primary description line

        • See our SEN data attribution blog to learn about varied formats and date-time possibilities within this String field, based on transaction type

      • effective_date

        • A transaction's effective date, which is always a banking day. There is no time component of the effective_date.

        • timezone: Pacific

        • format: YYYY-MM-DDT00:00:00 (ISO 8601 with time always zeroed out)

      • SEN_TRANSFER_RESPONSE (object)

        • timestamp (sub-object field, only present on certain transactions)

          • String, Date and time when a transaction took

          • timezone: Pacific

          • format: YY/MM/DD HH:MM:SS:ss.ss

  • FX

    • FX RFQ

      • quote_expiration

        • The timestamp indicating when the quote will expire.

        • timezone: UTC

      • value_date

        • Date on which funds are expected to be transferred to the beneficiary. There is no time component of the value_date.

        • timezone: Pacific

    • FX Execute market order

      • value_date

        • Date on which funds are expected to be transferred to the beneficiary. There is no time component of the value_date.

        • timezone: Pacific

    • FX Internal RFQ

      • quote_expiration

        • The timestamp indicating when the quote will expire.

        • timezone: UTC

      • value_date

        • Date on which funds are expected to be transferred to the beneficiary. There is no time component of the value_date.

        • timezone: Pacific

    • FX Execute internal market order

      • value_date

        • Date on which funds are expected to be transferred to the beneficiary. There is no time component of the value_date.

        • timezone: Pacific

    • GET Trades

      • begin_date

        • Optional, the beginning date range for history query; a blank value will default to current day. Note -- date fields ignored when is-real-time = true.

        • timezone: Pacific

      • end_date

        • Optional, the ending date range for history query; a blank value will default to current day. Note -- date fields ignored when is-real-time = true.

        • timezone: Pacific

      • trade_date

        • Date on which the trade was executed, with Pacific Time timestamp.

        • timezone: Pacific

      • value_date

        • Date on which funds are expected to be transferred to the beneficiary. There is no time component of the value_date.

        • timezone: Pacific

    • EXECUTE FX (or INTERNAL) Trade

      • value_date

        • Date on which funds are expected to be transferred to the beneficiary. There is no time component of the value_date.

        • timezone: Pacific

    • GET TRADE

      • trade_date

        • Date on which the trade was executed, with Pacific Time timestamp.

        • timezone: Pacific

      • value_date

        • Date on which funds are expected to be transferred to the beneficiary. There is no time component of the value_date.

        • timezone: Pacific

    • CREATE FX PAYMENT/ ADHOC PAYMENT

      • payment_timestamp

        • Most recent timestamp when the status of the payment changed

        • timezone: UTC

  • PAYMENT

    • GET Payments

      • begin_date

        • Required, the begin date range for payments query, which queries the Response entry_date. Timestamp does not factor.

        • timezone: Pacific

        • A reminder that GET payments is querying the date when an inbound payment arrived at Silvergate or an outbound payment was initiated, whereas GET history is querying when a payment posts to an account.

      • end_date

        • Optional, the ending date range for the payments query, which queries the Response entry_date. A blank value will default to current day. "End_date" must be within 32 days of "begin_date" and timestamp does not factor.

        • timezone: Pacific

        • A reminder that GET payments is querying the date when an inbound payment arrived at Silvergate or an outbound payment was initiated, whereas GET history is querying when a payment posts to an account.

    • GET Payment

      • payment_date

        • The date on which the payment is processed

        • timezone: Pacific

        • format: YYYY-MM-DDT00:00:00 (ISO 8601 with time always zeroed out)

      • entry_date

        • The date when the payment is first submitted into the payments system, which is not always the date it settles. For inbound payments, this is the day the Silvergate wire desk receives it. For outbound payments, this is the day the payment is initiated.

        • timezone: Pacific

        • format: YYYY-MM-DDT00:00:00 (ISO 8601 with time always zeroed out)

      • completion_date

        • The date of posting to the Silvergate bank account.

        • timezone: Pacific

        • format: YYYY-MM-DDT00:00:00 (ISO 8601 with time always zeroed out)

      • cancel_date

        • The cancelation date, if applicable

        • timezone: Pacific

        • format: [YYYY-MM-DD]T[HH:MM:SS.sss (ISO 8601 with actual time of cancelation)

      • time_stamp

        • The timestamp marks the last action on a payment and is critical as an input for POST and PATCH payment.

        • timezone: UTC

        • format: [YYYY-MM-DD]T[HH:MM:SS.sss (ISO 8601 with actual time of last update to the payment)

    • GET Payment Instructions

      • value_date

        • The date on which funds are expected to be transferred to the beneficiary. There is no time component of the value_date.

        • timezone: Pacific