All date properties will be in the ISO 8601 date format (i.e., 2013-10-03T13:38:44.754-05:00). Any dates passed into the API are expected to be UTC time and dates returned from the API will be in the time zone of the bank where the deposits are being held. An exception to this rule would be properties such as
birthDate which will contain zeroes for the time elements.
All decimal values have at most 2 digits of precision. The exception is any interest rate properties, which have up to 11 digits of precision.
Boolean values are returned as
Culture (in customer and statement) is a unique name for each culture based on RFC 4646. The name is a combination of an ISO 639-1 two-letter lowercase culture code associated with a language and an ISO 3166 two-letter uppercase subculture code associated with a country or region. Currently the Helix API is only supported in the US. The default culture for every program is
en-US, but additional cultures may be added on a per-program basis.
Country codes will follow the ISO 3166-1 alpha 3 standard as this is what is utilized on passports.
Strings are stored in SQL Server using the NVARCHAR datatype which is a UCS-2 encoding. String lengths for individual fields are quoted in characters, not bytes. However, some higher-order code point surrogate pairs may actually occupy 2 unicode characters. So the character length quoted for each field should be treated as an absolute upper bound on the number of characters, not a guarantee of allowing at least that many visible characters. To maintain compatibility with legacy systems, files emitted from Helix are in ASCII format. As such, any characters which do not fit into ASCII will either be coerced down into ASCII if possible, or stripped if not.
Any string values that are saved via the API that exceed the quoted field lengths will be silently truncated to the maximum length without warning or error.