Endpoint Proposal

[adamdecaf]

Here are my initial thoughts for OFAC endpoints.

We'd serve all endpoints at https://api.moov.io/v1/ofac/

POST /companies/:id/watch
- monitor company by id

POST /companies/watch?name=...
- monitor company by name, reparsed on each search

GET /companies/:id
- get company information and matches

PUT /companies/:id
- mark company as blocked or unblocked

DELETE /companies/:id/watch
- stop watching company

DELETE /companies/watch/:watchId
- stop watching company by watchId

POST /customers/:id/watch
- monitor customer

POST /customers/watch?name=...
- monitor customer by name, re-parse on each search

GET /customers/:id
- get customer information and matches

PUT /customers/:id
- mark customer as blocked or unblocked

DELETE /customers/:id/watch
- stop watching customer

DELETE /customers/watch/:watchId
- stop watching customer name


POST /search/address
- Search for address records matching the given search criteria.

POST /search/name?k=v
- fuzzy name search
- See: https://github.com/moov-io/ofac/issues/6

POST /search/alt?k=v
- fuzzy alternate name search

POST /search/company?k=v
- fuzzy company name search


GET /sdn/:id/addresses
- get addresses for a given SDN

GET /sdn/:id/alternateNames
- get alternate names for a given SDN

GET /sdn/:id
- get SDN information

[bkmoovio]

Do we want a search on all programs?

[bkmoovio]

For the customers and companies, are we going to retain customer and company data? its ok if we are, I'm just wondering.

[adamdecaf]

Do we want a search on all programs?

I'm not sure what you mean. The top mentions https://api.moov.io/v1/ofac/ as the base, so https://api.moov.io/v1/ofac/search/address would be a full URL. (Our app just knows about /search/address though.)

For the customers and companies, are we going to retain customer and company data? its ok if we are, I'm just wondering.

At least in the downloaded files and in a database we use, yes. I don't know if GDPR impacts this data storage.

[bkmoovio]

Adam,

At https://sanctionssearch.ofac.treas.gov/, search can be based on type, program, ID#. I'm not sure ACH would need that, but it may be useful to be able to search specifically on Cyber2 or a search on all programs, all types or an individual ID

[adamdecaf]

it may be useful to be able to search specifically on Cyber2 or a search on all programs, all types or an individual ID

Yea. I agree.

The Program list probably changes over time as politics changes, so we might need/want to offer an endpoint listing all possible options. Any program parameter might need to be a free-form string.

I'd think any ACH transaction would need checked against at least cyber2, but probably additional lists (if not the entire set of lists).

[bkmoovio]

Good point on checking all of the lists for ach. I think that is probably the way to go, SDN (SDN Comments), Alternate ID, and Address for all types and all programs. NON-SDN and other lists may be additional enhancement issues we want to do. Still getting my arms around the scope/needs.

Update *** - NON-SDN has the same file format, which is good.

[adamdecaf]

I think this set of scenarios would work for an ofac MVP. Thoughts @wadearnold and @bkmoovio ?

scenarios:
- find and inspect company
   - search: POST /search/company?k=v
   - get details: GET /companies/:id
   - add watch (i.e. webhook)
     - POST /companies/:id/watch OR POST /companies/name/:name/watch
   - remove watch:
     - DELETE /companies/:id/watch OR DELETE /companies/name/:name/watch
   - [un]block: PUT /companies/:id

- find and inspect customer
  - search:
    - POST /search/name?k=v OR POST /search/alt?k=v OR
  - get details: GET /customers/:id
  - add watch (i.e. webhook)
    - POST /customers/:id/watch OR POST /customers/name/:name/watch
  - remove watch:
    - DELETE /customers/:id/watch OR DELETE /customers/name/:name/watch
  - [un]block: PUT /customers/:id

- paygate:
  - Individual: "find and inspect customer" - reject if blocked or strong match
  - Business: "find and inspect company" - reject if blocked or strong match

- discover by address
  - search: POST /search/address

- SDN information
  - GET /sdn/:id
  - GET /sdn/:id/addresses
  - GET /sdn/:id/alternateNames

[wadearnold]

I would priorities customers over companies for the POC.
We end up creating a workflow for the API as well. If a strong correlation happens we need and approve or deny on that account. The fuzzy match then is tied as approved, false positive, for that customer/company. I don't think that we need a UX yet but we should mock the API endpoints and DB structure.