AMLAML monitoring for non-bank lenders, with no access to the institution’s system.
Five data sets exported from the existing lending software. AMLTracer applies the rules, opens the cases and prepares the cash and suspicious transaction reports for ONPCSB. Names and personal ID numbers stay with the institution.
The data comes to us; the system stays the institution’s.
The same rules we apply to mutual aid societies, without a direct database connection.
AMLTracer needs five data sets, not a connection. They are exported from the lending software the institution already runs; nothing is installed on its side.
The periodic export carries the identifiers from the institution’s own software and hashes of phone, address, IBAN and personal ID. Identity is retrieved only at the compliance officer’s request, and every look-up is logged.
The key is the ID from the institution’s system: a repeated delivery or a retroactive correction applies without duplicates. A complete export of the last 30 to 90 days beats a “changes only” one, because structuring and linked-transaction rules need history.
Two months monthly, while the rules are calibrated on the institution’s data. Then weekly, so the cash report to ONPCSB fits within the 3 working days. Daily if the export is automated.
Five data sets, as CSV or JSON Lines.
The fields below are the required ones. The full technical document, with every field, type and validation rule, is sent at the first call.
Customer
One row per customer, natural or legal person: all active ones plus those closed in the last 24 months.
- id_client
- type PF/PJ
- relationship date
- PEP and non-resident flags
- declared income
- hashes of phone, address, IBAN, personal ID
Beneficial owner
Legal persons only: who stands behind the company, with the PEP flag.
- id_client
- id_persoana
- percentage
- PEP flag
Contract
One row per credit granted: all running ones plus those closed in the last 24 months.
- id_contract
- id_client
- product
- grant date and amount
- instalments
- current balance
Transaction
One row per money movement, including cancelled or reversed ones, flagged as such.
- id_tranzactie
- date and time
- id_client
- type (fixed vocabulary)
- channel: cash, transfer, card…
- amount in lei
Relationship
Who is linked to whom: guarantor, co-payer, administrator, proxy, spouse.
- id_client
- id_persoana
- role
- contract, if any
Identity, on request
Name, personal ID, address, identity document: not in the periodic export. Requested by the officer for one case, and logged. How exactly, hashes only or identity encrypted with the institution’s own key, is decided with each institution.
The payment channel (cash, transfer, card) is the field that matters most: the cash report and two thirds of the rules depend on it. If the software does not keep it, it is derived from the treasury ledger account.
Three ways the data reaches us.
CSV or JSON Lines, one file per data set, uploaded in the app by the compliance officer for the pilot, then by SFTP with a key per institution, picked up every night. The default: minimal effort, full control over what leaves.
defaultDedicated views, read only, as with the mutual aid societies already connected. Suits on-premise software with an open IT team.
if the system allows itThe institution’s system sends the records as they happen. Only when you need screening at the moment a credit is approved; PepCheck’s API already covers that part.
optionalScreening at origination, through an API. Import through an API, on request.
Two different things, kept apart: what is available today and what we build with the first institution that needs it.
PEP and sanctions screening at the moment a credit is approved
The lending software sends the name and date of birth, receives the matches as JSON and decides the flow before granting. Over 300 lists through OpenSanctions or Dilisense, an audit trail for every call, a certificate for every person screened.
curl -X POST https://pepcheck.ro/api/v1/pep/ \
-H "Authorization: Bearer pk_live_…" \
-H "Content-Type: application/json" \
-d '{"name": "Maria Ionescu", "type": "person", "birth_date": "1982-09-17", "nationality": "ro"}'{
"query": "Maria Ionescu",
"type": "person",
"source": "OpenSanctions",
"result_status": "negative",
"risk_score": 0,
"total_matches": 0,
"matches": [],
"response_time_ms": 850
} PEP API · Full documentation, with Python and JavaScript examples (in Romanian)
Transactions sent as they happen
For institutions with a technical team: the same five data sets, sent by the lending software to AMLTracer as they happen, with a key per institution and the same validation and report as for files. Not built yet: we build it with the first institution that needs it, on a real case, once file import is running.
Until then, file export covers everything the law requires, including the 3-day deadline for the cash report, at a weekly or daily rhythm.
What the first three months look like.
No long-term contract at the start: a pilot on real data, with us behind the first import.
A 30-minute call: the lending software, what it exports today, how cash and suspicious transaction reports are filed now.
week 1The institution’s export is mapped to the five data sets once. Column names are proposals and adapt to what already exists.
week 2One month of data is uploaded. The validation report comes back at once, then the rules run and open the first cases.
week 3Two months of monthly imports while thresholds are tuned to the institution’s customer base. Then weekly, and the cases become routine.
months 2–3One thing to know at the start: the lending software.
The rest is settled in a 30-minute call. If the software exports CSV or Excel, the first import can happen within two weeks.