Crediting of Deposits Deposits made after the deposit cutoff time and deposits made on either holidays or days that are not our business days will be credited to your account on the next business day.
Processing of Deposit files The use of compression is recommended in order to reduce electronic data transfer times, and storage capacity requirements. Data encryption will be used to ensure the privacy of registry escrow data. Files processed for compression and encryption will be in the binary OpenPGP format as per OpenPGP Message Format -‐ RFC 4880, see Part A, Section 9, reference 3 of this Specification. Acceptable algorithms for Public-‐key cryptography, Symmetric-‐key cryptography, Hash and Compression are those enumerated in ▇▇▇ ▇▇▇▇, not marked as deprecated in OpenPGP IANA Registry, see Part A, Section 9, reference 4 of this Specification, that are also royalty-‐free. The process to follow for the data file in original text format is: (1) The XML file of the deposit as described in Part A, Section 9, reference 1 of this Specification must be named as the containing file as specified in Section 5 but with the extension xml. (2) The data file(s) are aggregated in a tarball file named the same as (1) but with extension tar. (3) A compressed and encrypted OpenPGP Message is created using the tarball file as sole input. The suggested algorithm for compression is ZIP as per ▇▇▇ ▇▇▇▇. The compressed data will be encrypted using the escrow agent’s public key. The suggested algorithms for Public-‐key encryption are Elgamal and RSA as per ▇▇▇ ▇▇▇▇. The suggested algorithms for Symmetric-‐key encryption are TripleDES, AES128 and CAST5 as per ▇▇▇ ▇▇▇▇. (4) The file may be split as necessary if, once compressed and encrypted, it is larger than the file size limit agreed with the escrow agent. Every part of a split file, or the whole file if not split, will be called a processed file in this section. (5) A digital signature file will be generated for every processed file using the Registry Operator’s private key. The digital signature file will be in binary OpenPGP format as per RFC 4880 Section 9, reference 3, and will not be compressed or encrypted. The suggested algorithms for Digital signatures are DSA and RSA as per ▇▇▇ ▇▇▇▇. The suggested algorithm for Hashes in Digital signatures is SHA256. (6) The processed files and digital signature files will then be transferred to the Escrow Agent through secure electronic mechanisms, such as, SFTP, SCP, HTTPS file upload, etc. as agreed between the Escrow Agent and the Registry Operator. Non-‐electronic delivery through a physical medium such as CD-‐ROMs, DVD-‐ROMs, or USB storage devices may be used if authorized by ICANN. (7) The Escrow Agent will then validate every (processed) transferred data file using the procedure described in Part A, Section 8 of this Specification.
Payment of Deposits In the event any depositor does not accept the obligation of the Assuming Institution to pay any Deposit liability of the Failed Bank assumed by the Assuming Institution pursuant to this Agreement and asserts a claim against the Receiver for all or any portion of any such Deposit liability, the Assuming Institution agrees on demand to provide to the Receiver funds sufficient to pay such claim in an amount not in excess of the Deposit liability reflected on the books of the Assuming Institution at the time such claim is made. Upon payment by the Assuming Institution to the Receiver of such amount, the Assuming Institution shall be discharged from any further obligation under this Agreement to pay to any such depositor the amount of such Deposit liability paid to the Receiver.
Release of Deposits Escrow Agent will make available for electronic download (unless otherwise requested) to ICANN or its designee, within twenty-‐four (24) hours, at the Registry Operator’s expense, all Deposits in Escrow Agent’s possession in the event that the Escrow Agent receives a request from Registry Operator to effect such delivery to ICANN, or receives one of the following written notices by ICANN stating that: 6.1. the Registry Agreement has expired without renewal, or been terminated; or 6.2. ICANN has not received a notification as described in Part B, Sections 7.1 and
Time Deposits Without prejudice to any right of set-off any Secured Party may have under any other Finance Document or otherwise, if any time deposit matures on any account the Chargor has with any Secured Party within the Security Period when: (a) this Security has become enforceable; and (b) no Secured Liability is due and payable, that time deposit will automatically be renewed for any further maturity which that Secured Party considers appropriate.