Standards & citations
Every threshold, format, and required field in the Constitution traces to a standard or a regulator, and the citation lives in the code. This page lists every standard the fintech rules encode and, for each, what the code actually checks.
The enforcement column states the mechanism, not a compliance claim: SINA computes an IBAN's mod-97 checksum for real, but it does not screen an address against a sanctions list and it does not perform a PCI assessment. Where a rule is a thin stand-in for a deeper obligation, the row says so.
Rules fall into three tiers, kept apart in the code:
- Format: checksums and code lists. Deterministic; a payload satisfies them or it doesn't.
- Regulatory: thresholds from real regulation. A
flagrecords the finding in the audit trail, anescalateforces a governed component, arejectrefuses outright. - SINA policy: tunable product defaults (dual control, step-up limits). These are not law; tune them to your own risk appetite.
When the gate blocks a request, the standard from the matching row travels
with the violation into the audit record, so an auditor can trace a block to
the rule that made it.
This table is generated from the schemas
The catalog lives in the constitution package, not in this page, and a guard test binds the two: a rule citing a standard the catalog omits fails the build, and so does a catalog entry citing something no rule enforces.
What the gate enforces, and where it stops
As a render-time gate, SINA acts on a request in five ways: it validates structure and format, it flags or escalates on a threshold, it forces a disclosure to be acknowledged, it requires a step-up or second approver, and it redacts the audit record. Every row below is one of those five moves.
Three kinds of control sit outside that reach. SINA does not screen names or addresses against sanctions or PEP lists, it does not make lending or eligibility decisions, and it does not hold a money-transmitter license. Each needs a service and live data a UI gate never sees; SINA runs in front of them and does not replace them. A few gate-shaped rules are simply not built yet, such as strong customer authentication for EU flows and open-banking consent. To add one, see write a rule.
Fintech
Format & structure
Checksums and code lists. Deterministic: a payload either satisfies them or it doesn't.
| Standard | What SINA actually checks | Where |
|---|---|---|
| ISO 4217 | Currency must be one of 8 supported codes (USD, EUR, GBP, CAD, AUD, CHF, JPY, BHD), not the full ISO table. Amounts are integer minor units with the correct per-currency exponent (JPY 0, BHD 3, rest 2), never floats. |
|
| ISO 13616 / ISO 7064 | Full mod-97 (ISO 7064) checksum, computed rather than pattern-matched. Structure is 2-letter ISO 3166-1 country + 2 check digits + BBAN, capped at 34 chars. |
|
| ISO 9362 | Structural validation only: 8 or 11 characters, well-formed bank/country/location. Optional on the SEPA leg (the IBAN-only rule, Regulation (EU) 260/2012) and checked when present. No SWIFT directory lookup, and no SWIFT MT messaging. |
|
| ISO/IEC 7812 | Luhn check digit, computed over a 13 to 19 digit PAN. |
|
| ABA routing number | 9 digits with the 3-7-1 weighted mod-10 check digit, computed. |
|
| ISO 20022 | Two constraints only: the remittance `reference` is capped at 140 chars, and the minor-units amount model satisfies the fractional-digit cap by construction. SINA does not implement ISO 20022 messages (no pain.001 / pacs.008). |
|
| PCI-DSS v4.0 Req 3.3.1 | A field-name deny-list (cvv, cvv2, cvc2, cav2, cid, pin, pinblock, track, track1, track2): the strict schema rejects the payload and the audit redaction drops the fields, so they can never reach a log. This is a storage guard, not a PCI assessment. |
|
Regulatory
Real regulations. These are not yours to loosen casually.
| Standard | What SINA actually checks | Where |
|---|---|---|
| 31 CFR 1010.410(e) / 1020.320 | A wire at or above $3,000 must carry originator and beneficiary name + address; missing information escalates to a governed dialog. Amount band, USD only. |
|
| 31 CFR Chapter X | A wire at or above $5,000 is flagged for SAR review. A `flag` records the finding in the audit trail; it does not block the action. |
|
| 31 CFR 1010.311 | An amount above $10,000 is flagged as CTR-reportable. A `flag` records it in the audit trail; it does not block. USD only. |
|
| FATF R.16 | A crypto withdrawal above $1,000 without authorization escalates to a governed dialog. Amount band only: SINA does not screen the destination address against an allowlist or a sanctions list. |
|
| Nacha Operating Rules | A same-day ACH entry above $1,000,000 is a hard reject: the payment cannot proceed and no component mounts. USD only. |
|
| 31 CFR 1020.220 | KYC verification escalates to an identity step-up (second factor). A simplified stand-in: a production CIP would layer document checks, sanctions/PEP screening and ongoing due diligence onto this envelope. SINA implements none of those. |
|
| Reg E (12 CFR 1005) | A dispute requires a step-up before it is filed, and a mandatory disclosure must be acknowledged before the flow proceeds. SINA does not implement the regulation's error-resolution timelines. |
|
| Reg Z / TILA (12 CFR 1026) | A credit request cannot proceed until the disclosure is acknowledged, and a request above $5,000 is flagged for review. SINA gates the acknowledgement; it does not author or verify the disclosure's content. |
|
| FINRA Rule 2111 | A trade requires an explicit order confirmation (second factor) before it is placed. SINA does not run a suitability determination, market-hours check, or position cap. |
|
| FINRA Rule 2264 / Reg T | Enabling margin forces the margin disclosure to be acknowledged before it can proceed. SINA gates the acknowledgement; it does not compute margin requirements. |
|
SINA policy
Tunable product defaults, not law. Set these to your own risk appetite.
| Standard | What SINA actually checks | Where |
|---|---|---|
| SINA dual-control | Above a per-rail limit an action escalates and needs a second approver. The approval is bound to a hash of the exact terms, recomputed server-side (so an approved $5,000 cannot execute as $60,000), and the approver must differ from the server-known initiator (no self-approval). Both binding failures are hard rejects. Tune the limits to your own risk appetite. |
|
| SINA USD-only bands | Every amount band above is defined in USD; no FX equivalence is computed. A non-USD payload passes format validation and carries a POLICY_BANDS_NOT_EVALUATED flag in the audit trail instead of silently passing. Integrators outside USD chain their own bands after the stock policy. |
|
| SINA step-up policy | A second factor is required before a sensitive, non-monetary action completes: adding a payee or authorized user, linking an account, issuing a card, cancelling/replacing a card, changing security settings, and P2P above $2,500. Tunable. |
|
Not legal advice