Audit Trails and Identity Verification for Fintech APIs

A financial document's audit trail needs four things to be worth having: a cryptographic signature bound to the document, a tamper-evident seal that reveals any change made after signing, a certificate recording when and where each party signed and by whom, and a complete event history. If any one of those lives only in a vendor's dashboard rather than returning through the API, your platform cannot produce the record later.

That distinction is the whole question for anyone building a lending, wealth, or account-opening product. Signing is easy. Proving what happened, eighteen months later, to somebody who is not inclined to take your word for it, is the part that decides whether the workflow survives contact with an examiner or a dispute.

What has to be in the audit trail?

Verdocs attaches all of the following to every completed document, and returns them through the API rather than keeping them in a portal:

• A PKI digital signature. Public Key Infrastructure, the standard banks and governments already rely on, backed by public and private certificates.
• A tamper-evident seal, so any alteration after execution is detectable rather than arguable.
• A signed certificate recording when and where the document was signed, and by whom.
• A full event history of everything that happened to the document, including opens, declines, and the authentication each party cleared.
• Encryption at rest using 2048-bit RSA private keys held in Hardware Security Modules, so no unauthorized party can read them, including Verdocs developers.

The test to apply to any vendor is narrow and useful: ask what comes back with the finished document. A signing screen is easy to demonstrate. An evidence package that arrives in your own system is the thing you are actually buying.

Worth knowing what the record has to carry, because it shapes what you ask for. ESIGN treats an electronic signature as valid where the signer's intent to sign is clear, the signer consented to transacting electronically, the signature is attached to or logically associated with the record, and the record is retained in a form that can be accurately reproduced. An event history that captures consent and authentication alongside the signature is what makes those four demonstrable later rather than assumed.

How should identity verification scale?

Not uniformly, which is the mistake most implementations make. A statement acknowledgment and a six-figure loan note carry different risk, so paying for the same identity assurance on both means overpaying on one and under-protecting the other.

The workable model is a ladder set per document type: creator link, in-person link, guest email, PIN code, verified user, MFA or SMS, knowledge-based authentication, and live ID scan. Each step a signer clears is recorded in the same event history as the signature, so the evidence reflects the assurance level you actually chose rather than the one you meant to. Knowledge-based authentication and ID scan are per-transaction add-ons, which is what makes tiering worth doing rather than a rounding error.

For a platform, the practical result is that assurance becomes a field on the document type in your own data model, decided once per workflow.

Which documents actually run through this?

Three families, and a platform in this space usually carries all three.

Wealth and advisory onboarding. Advisory agreements, Investment Policy Statements, Form ADV Part 2A acknowledgments, W-9s, KYC and AML verification, custody agreements, and the account-opening paperwork underneath them. These arrive as a package rather than as one document, so bundling and per-document assurance decide whether the workflow is usable at all. On the record side, SEC and FINRA recordkeeping expectations cover the delivery and consent record and not the signature alone, which is another reason the event history matters more than the signing screen.

Lending and credit. The application, the note, and the disclosures, with a borrower, a co-signer, a guarantor, and an internal approver all touching one file in a required order. FFIEC guidance treats multi-factor authentication as part of a sound posture for electronic banking, so assurance again belongs on the document type rather than on the account.

Investment subscriptions. Subscription agreements where the routing depends on an answer inside the document, most often whether the investor is accredited.

That last case earns its own question for any vendor: can routing branch on document data, or only follow a fixed signer list? A compliance review required above a threshold is easy to describe and not universally supported.

Can multiple parties sign in a required order?

Yes, and financial files usually demand it. Parallel and sequential routing supports signers, approvers, and carbon copies in whatever order the file requires, and each party can carry its own authentication level.

That last part matters more than it sounds. On a loan file the applicant, the co-applicant, and an internal approver are not equivalent parties, and treating them as one signer list is how workflows end up with a weaker link than the file's risk warrants.

Is Verdocs SOC 2 Type II certified?

No, and this is worth answering plainly because the question comes up in exactly this form.

Verdocs holds a SOC 2 Type I attestation. The report is available on request under a mutual NDA. Type I evaluates whether controls are suitably designed at a point in time; Type II additionally evaluates whether they operated effectively over a period. Type II is the more demanding standard, and any vendor that has one should be able to name the report and its date.

Two further notes, since precision matters on this topic. SOC 2 is an attestation engagement rather than a certification, which is why careful vendors say "attested". And an attestation is not the same as the controls themselves: the PKI signatures, the HSM key storage, and the audit trail described above are what actually protect a document, and they are inspectable on any envelope you send in a free sandbox.

Verdocs is also HIPAA compliant, which matters for financial platforms carrying health information in underwriting or claims-adjacent workflows.

What about signatures outside the United States?

Signatures are ESIGN and UETA compliant, with eIDAS Simple Electronic Signature and Advanced Electronic Signature support, and Qualified Electronic Signature available through qualified trust service provider partnerships. They are legally valid in 50+ countries and 60+ jurisdictions.

The honest caveat for platform teams: eIDAS assurance levels are a spectrum, and which level a particular instrument requires in a particular market is a question for your customer's counsel rather than for a vendor's comparison table. What a signing provider can tell you is which levels it supports and what evidence it returns.

Where should signing actually happen?

Inside your product, if the workflow is yours.

There are three shapes this takes. Standalone eSign sends the user to a separate tool. Integrated eSign connects that tool to your product, but the signing experience still belongs to the vendor. Embedded signing infrastructure renders inside your own product, on your domain, in your styles, with no redirect.

For a financial platform the difference is not cosmetic. An applicant part-way through an account opening who gets handed to an unfamiliar third-party domain at the moment of commitment is an applicant you can lose for reasons that have nothing to do with your product. Verdocs ships web components rather than iframes, so any control can be overridden and styled with standard CSS.

White-labeling reaches the multi-tenant level as well, so each institution, program, or brand on your platform gets its own logo, colors, domain, and email sender. The financial services platform page covers how that maps onto loan origination, account opening, servicing, and advisory workflows.

What should a platform ask before committing?

Five questions that separate signing infrastructure from a tool with an API attached:

1. Does the evidence package return through the API? Certificate, seal, and full event history, into your system, not only into their dashboard.
2. Can I set authentication per document type? A single global setting means paying identity-verification rates on documents that do not need them.
3. Does routing support approvers distinctly from signers? Financial files rarely have one flat signer list.
4. Does white-labeling reach my customers' brands, or only mine? For a platform reselling signing, multi-tenant depth is the requirement.
5. What is the compliance posture, stated exactly? Ask for the report name and date rather than a badge.

The part that is easy to get wrong

Most evaluations of signing vendors spend their time on the signing screen, which is the part every vendor has solved. The durable question is what your platform holds afterward: whether the record is complete, whether it lives in your system, and whether the assurance level on each document matches the money at stake.

Fuller detail on the compliance surface, including how to request the SOC 2 report, lives on the legal compliance page.