An ASPSP establishes an SCA procedure for their corporate customers that adopts best practice techniques laid out by the EU's eIDAS regulation. . Business Payment Service User (PSU)'s that prepare files of payments within their enterprise resource planning (ERP) package are recommended to apply a company seal (electronic signature) with a commitment type of #proofOfCreation, before combining the payment order data and signature into an 'Associated Signature Container' (ASiC) for transmission to the ASPSP. On receipt, the ASPSP routes the payment order into its 'decoupled SCA procedure', whereby one or more personal authorisation PSU's are requested to approve the payment order on behalf of the business PSU. As there can be many payment instructions within a file, the approver must rely on the #proofOfCreation as evidence that the instructions have not been maliciously modified, since creation. Personal approval is captured via the creation of electronic signatures with a commitment type of #proofOfApproval. These additional signatures are added to the ASiC. The ASiC represents unambiguous and demonstrable evidence of explicit consent to execute the related payment instructions.

With respect to IT Security threats, the business PSU's must work on the assumption that their systems have already been breached. They must plan for the possibility that the integrity of the systems that create the payments are compromised. This would undermine the integrity of the #proofOfCreation. It is essential that the business PSU's understand how to quickly invalidate/revoke the SCA proof for any future dated payment instructions that have already been transmitted to the ASPSP, but have not yet been booked. It is also essential that the business PSU understands their (payer) liability and right of recourse, in the event of fraud.