LimitRail - playbook per integratori esterni
Questo playbook spiega come un sistema esterno integra LimitRail per valutare prezzi, limiti, soglie cliente e consumo runtime. LimitRail non apre conti, non esegue pagamenti, non possiede il ledger e non calcola il saldo contabile. Il sistema chiamante esegue l'operazione finanziaria; LimitRail restituisce la decisione di policy.
1. Concetto base
L'integrazione ruota attorno a tre riferimenti.
| Riferimento | Chi lo governa | Uso |
|---|---|---|
externalAccountRef |
Sistema chiamante | Riferimento conto opaco. Non deve contenere IBAN, nome, email, codice fiscale o altri dati personali. |
productId / productCode |
LimitRail | Il conto viene registrato con il productId restituito dal catalogo. Il productCode resta il riferimento business per allineare il prodotto del core. |
operationCode |
Accordo tra integratore e LimitRail | Codice operativo inviato in evaluate/commit. Non esiste un mapping: se il core invia ATM_WITHDRAWAL, LimitRail configura ATM_WITHDRAWAL. |
externalOperationRef non decide la policy. Serve solo a correlare la decisione
LimitRail con l'evento del sistema esterno.
2. Autenticazione e scope
Usa OAuth client credentials. Il client ottiene un bearer token con
POST /connect/token e poi chiama le API v1.
| Scope | Quando serve |
|---|---|
limitrail.catalog.read |
Leggere prodotti, operation catalog e policy inputs. |
limitrail.accounts.read |
Leggere conti, pricing applicabile, contatori e soglie cliente. |
limitrail.accounts.write |
Registrare conti, aggiornare stato, attributi e soglie cliente. |
limitrail.evaluate |
Valutare policy con POST /v1/policy/evaluate. |
limitrail.usage.write |
Confermare consumo, cancellare reservation o stornare usage. |
limitrail.audit.read |
Leggere eventi runtime per supporto, audit o riconciliazione. |
3. Setup iniziale dell'integratore
Prima di inviare richieste runtime, l'integratore deve leggere il catalogo.
GET /v1/products?take=25RecuperaproductId,productCode, stato e valuta. IlproductIdè il valore richiesto oggi dalla registrazione conto; ilproductCodeè il codice business da mappare nel sistema chiamante.GET /v1/operations?take=25Recupera gli operation code accettati. Il campocodeè il valore da inviare comeoperationCode.GET /v1/policy-dimensionsRecupera i dati che possono influenzare regole e contatori. Le dimensioni con sourceREQUEST_METADATAvanno inviate inmetadata; quelle con sourceACCOUNT_ATTRIBUTEvanno salvate sul conto.
4. Lifecycle conto
Quando un conto entra nel perimetro LimitRail, registra il contratto:
POST /v1/account-contracts
{
"externalAccountRef": "ACC_7F3A92_001",
"productId": "7b2d8b9f-1a4c-4f3b-9c10-35e4b7a98c21",
"segmentCode": null,
"openedAtUtc": "2026-07-05T10:00:00Z",
"attributes": {
"customer_tier": "STANDARD",
"residency_country": "ITA"
}
}
L'integratore non passa la versione del piano condizioni. LimitRail la risolve da prodotto, segmento o assegnazione account-level. Account deal e override di policy sono funzioni backoffice, non campi di onboarding pubblico.
Quando il conto cambia prodotto, segmento, stato o blocco operativo, aggiorna il contratto:
PUT /v1/account-contracts/{id}
Se status = BLOCKED, invia anche blockType e blockReasonCode. Se
status = CLOSED, il runtime blocca le valutazioni e il contratto non viene
riaperto.
5. Attributi conto
Gli attributi conto sono fatti stabili riutilizzati dalle regole senza inviarli
in ogni richiesta. Esempi: customer_tier, residency_country,
regulatory_status.
PUT /v1/account-contracts/{id}/attributes
{
"code": "customer_tier",
"value": "PREMIUM"
}
LimitRail accetta solo attributi registrati come ACCOUNT_ATTRIBUTE, attivi e
compatibili con eventuali valori ammessi.
6. Soglie scelte dal cliente
Alcuni limiti possono essere configurabili dal cliente finale. Il cliente può solo ridurre la soglia entro i confini del prodotto; non può aumentarla oltre il massimo di prodotto.
Lettura soglie disponibili:
GET /v1/accounts/{externalAccountRef}/limit-settings
Impostazione soglia:
PUT /v1/accounts/{externalAccountRef}/limit-settings/{limitRuleCode}
{
"limitAmount": 200.00,
"source": "CUSTOMER",
"reason": "Customer-selected ATM daily amount limit"
}
Per limiti a conteggio usa limitCount. Quando la soglia cliente è attiva, la
risposta runtime mostra thresholdSource = CUSTOMER_SETTING.
Le soglie cliente non sono deroghe. Una deroga autorizza temporaneamente un superamento; una soglia cliente rende il conto più restrittivo.
7. Valutazione runtime
La chiamata principale e':
POST /v1/policy/evaluate
{
"externalAccountRef": "ACC_7F3A92_001",
"operationCode": "ATM_WITHDRAWAL",
"amount": 120.00,
"currencyCode": "EUR",
"externalOperationRef": "OP_20260705_00001",
"occurredAtUtc": "2026-07-05T10:05:00Z",
"metadata": {
"terminal_country": "ITA"
},
"mode": "PREVIEW",
"idempotencyKey": null
}
metadata deve contenere solo fatti. Esempi corretti:
destination_country, terminal_country, resulting_balance_after_operation,
average_monthly_balance. Esempi da evitare: high_amount,
discounted_fee, domestic_fee, limit_exceeded.
Modalità' runtime
| Mode | Effetto |
|---|---|
PREVIEW |
Valuta policy e fee senza scrivere consumo. È il default se mode manca. |
RESERVE_CAPACITY |
Valuta e prenota capacità' di limite per un flusso asincrono. Richiede idempotencyKey. |
COMMIT_USAGE |
Valuta e registra subito consumo. Richiede idempotencyKey. |
Se la decisione è DENIED_BY_POLICY, il sistema chiamante non deve procedere.
Se è ALLOWED, WARNING o FEE_CALCULATED, il chiamante prosegue secondo il
proprio processo operativo.
8. Reserve, commit, cancel e reverse
Per flussi asincroni usa due fasi.
POST /v1/policy/evaluateconmode = RESERVE_CAPACITY. Se la policy consente l'operazione, LimitRail restituiscecapacityReservationId.Quando l'operazione esterna viene confermata:
POST /v1/usage/commit
{
"capacityReservationId": "2b7e4f0c-6f2a-4d34-a76e-9d91f9a53112",
"idempotencyKey": "COMMIT_OP_20260705_00001",
"externalAccountRef": "ACC_7F3A92_001",
"operationCode": "ATM_WITHDRAWAL",
"amount": 120.00,
"currencyCode": "EUR",
"externalOperationRef": "OP_20260705_00001",
"occurredAtUtc": "2026-07-05T10:05:00Z",
"metadata": {
"terminal_country": "ITA"
}
}
- Se l'operazione viene abbandonata prima del commit:
POST /v1/capacity-reservations/{id}/cancel
- Se un consumo già applicato deve essere compensato:
POST /v1/usage/{id}/reverse
con reversalIdempotencyKey.
La stessa idempotency key con lo stesso payload deve restituire lo stesso esito. La stessa chiave con payload diverso è un errore di integrazione.
9. Come leggere la risposta evaluate
| Campo | Significato |
|---|---|
decision |
Esito: ALLOWED, DENIED_BY_POLICY, WARNING, FEE_CALCULATED. |
reasonCode |
Motivo sintetico o codice regola che ha deciso. |
fees / totalFees |
Commissioni calcolate da LimitRail. |
ruleResults |
Regole limite valutate, soglie prodotto/cliente e consumi. |
limitImpacts |
Proiezione dei contatori dopo l'operazione. |
policyExceptionTrace |
Deroghe considerate o consumate. |
usedDimensions |
Dati usati nella decisione, esclusi quelli sensibili. |
missingDimensions |
Dati richiesti da regole ma non disponibili. |
unusedDimensions |
Metadata inviati ma non usati da regole rilevanti. |
policyProvenance |
Origine della policy: prodotto, segmento o account-level. |
10. Letture utili
| Endpoint | Uso |
|---|---|
GET /v1/account-contracts/by-account/{externalAccountRef} |
Verificare prodotto, segmento, stato e policy risolta. |
GET /v1/accounts/{externalAccountRef}/pricing |
Mostrare o diagnosticare le regole prezzo applicabili. |
GET /v1/accounts/{externalAccountRef}/usage-counters?take=100 |
Mostrare consumo corrente, capacità' residua e soglie cliente. |
GET /v1/usage?from={from}&to={to} |
Riconciliare eventi di consumo applicati o stornati. |
GET /v1/capacity-reservations?from={from}&to={to} |
Controllare reservation aperte, confermate, cancellate o scadute. |
Le liste operative sono paginate e devono usare finestre temporali. Non usarle come export massivo.
11. Enum che l'integratore deve conoscere
Usare valori UPPER_SNAKE_CASE.
| Campo | Valori principali |
|---|---|
| Account status | PENDING, ACTIVE, BLOCKED, CLOSED |
| Account block type | NONE, OPERATIONAL_RISK, REGULATORY_JUDICIAL, TECHNICAL_CLOSURE |
| Evaluation mode | PREVIEW, RESERVE_CAPACITY, COMMIT_USAGE |
| Policy decision | ALLOWED, DENIED_BY_POLICY, WARNING, FEE_CALCULATED |
| Customer limit source | CUSTOMER, OPERATOR |
| Customer limit status | ACTIVE, CANCELLED |
| Reservation status | RESERVED, CONFIRMED, CANCELLED, EXPIRED |
| Usage event status | APPLIED, REVERSED |
Gli enum di configurazione pricing e limiti appartengono al manuale operativo, non al payload standard dell'integratore.
12. Checklist integrazione
- Recuperare token con OAuth client credentials.
- Leggere prodotti, operazioni e policy inputs prima del runtime.
- Registrare ogni conto con riferimento opaco.
- Aggiornare stato conto, blocco, segmento e prodotto quando cambiano.
- Salvare come attributi solo fatti stabili.
- Inviare in
metadatasolo fatti della singola operazione. - Usare
operationCodediretto. - Non inviare
externalSystemCodeoexternalOperationCode. - Non inviare
conditionPlanVersionId. - Usare idempotency key per ogni chiamata che scrive stato.
- Leggere decisione, fee, rule results e limit impacts prima di proseguire.