moov-io / paygate

A RESTful API enabling electronic payments to be submitted and received without a deep understanding payment file specification

moov-io/paygate

Project Status

We have designed and released achgateway for orchestrating ACH uploads in real production scenarios. Please read over our guide to achgateway and give us feedback on the design or your experience! We have also realized that KYC/KYB, data modeling, workflows, and risk analysis are difficult to open-source. We are interested in hearing how you have solved these problems internally and want to develop something in the open. Thank you to everyone who has contributed and helped us grow.

---

Moov Paygate is a RESTful HTTP API enabling Automated Clearing House (ACH) transactions and returns to be processed with an Originating Depository Financial Institution (ODFI) without a deep understanding of a full NACHA file specification.

If you believe you have identified a security vulnerability please responsibly report the issue as via email to [email protected]. Please do not post it to a public issue tracker.

Docs: Project | API Endpoints | Admin API Endpoints

This project is sponsored by Moov Financial, Inc which offers commercial support, hosting, and additional features. Refer to our Moov's payout documentation for more information.

Getting Started

We publish a public Docker image moov/paygate from Docker Hub or use this repository. No configuration is required to serve on :8083 and metrics at :9093/metrics in Prometheus format. We also have docker images for OpenShift.

Start PayGate and its dependencies:

docker-compose up

Create an example Transfer

go run examples/getting-started/main.go

Created source customer 1b1747b770bc471a478a9ae22d99973e956199aa
Customer status is verified
Created source customer account 164213fa5901431dffa324fbf16e10210fe3f6da
Approved source account
===========
Created destination customer 81393acbf9b45abc164c51689aa095528affc8e1
Customer status is verified
Created destination customer account 2a1969745050c7ccd9b2d9ba4abaf49c07c4d42e
Approved destination account
===========
{
  "transferID": "dd4dfea8ea5fe52d46d9749fc84ad6695d3d2a05",
  "amount": {
    "currency": "USD",
    "value": 125,
  },
  "source": {
    "customerID": "1b1747b770bc471a478a9ae22d99973e956199aa",
    "accountID": "164213fa5901431dffa324fbf16e10210fe3f6da"
  },
  "destination": {
    "customerID": "81393acbf9b45abc164c51689aa095528affc8e1",
    "accountID": "2a1969745050c7ccd9b2d9ba4abaf49c07c4d42e"
  },
  "description": "test transfer",
  "status": "processed",
  "sameDay": false,
  "returnCode": {
    "code": "",
    "reason": "",
    "description": ""
  },
  "created": "2020-07-10T16:59:19.6422361Z"
}
Success! A Transfer was created.

An ACH file was uploaded to a test FTP server at ./testdata/ftp-server/outbound/
total 8
-rw-r--r--  1 adam  staff  950 Jul 10 09:59 20200710-071000301.ach

View all uploaded files with achcli from moov-io/ach.

achcli ./testdata/ftp-server/outbound/*.ach

Uploaded ACH file

Describing ACH file './testdata/ftp-server/outbound/20200710-071000301.ach'

  Origin     OriginName    Destination  DestinationName  FileCreationDate  FileCreationTime
  221475786  Teachers FCU  071000301    FRBATLANTA       200710            1259

  BatchNumber  SECCode  ServiceClassCode  CompanyName  DiscretionaryData  Identification  EntryDescription  DescriptiveDate
  1            PPD      200               John Doe                        MOOVO3S6TA      test trans        200710

    TransactionCode  RDFIIdentification  AccountNumber      Amount  Name                    TraceNumber      Category
    32               10200101            654321             125     Jane Doe                221475784797987

    TransactionCode  RDFIIdentification  AccountNumber      Amount  Name                    TraceNumber      Category
    27               22147578            123456             125     John Doe                221475784797988

  BatchCount  BlockCount  EntryAddendaCount  TotalDebitAmount  TotalCreditAmount
  1           1           2                  125               125

Micro-Deposits

Micro Deposits are used to validate a customer can access an account at another Financial Institution. Typically they are two deposits under $0.50 and a balancing withdraw. The customer supplies both deposited amounts as verification.

Start PayGate and its dependencies:

docker-compose up

Setup the micro-deposit account to originate from.

go run examples/micro-deposits-setup/main.go

Created micro-deposit source customer df7a3f35038be2b3e332625e94b58b66fed703b8
Customer status is verified
Created customer account 460026b50830443a77253a0e6c7ca1bebae8a731
Approved micro-deposit source account
===========
In ./examples/config.yaml replace the 'validation:' YAML block with:
validation:
  microDeposits:
    source:
      customerID: "df7a3f35038be2b3e332625e94b58b66fed703b8"
      accountID: "460026b50830443a77253a0e6c7ca1bebae8a731"
===========

Restart PayGate with 'docker-compose up' and run go run /examples/micro-deposits/main.go

After updating PayGate's config and restarting (docker-compose restart)

go run examples/micro-deposits/main.go

Created customer 2774a3f7a5eef61dd6e2a18ac5d939dd35099161 to approve
Customer status is verified
Created destination customer account bd2b81017ecf791cdb3e722eebbe675ae67357d9
Initiating micro-deposits...
Initiated micro-deposits for destination account
Found micro-deposits: [
  {
    "currency": "USD",
    "value": 21
  },
  {
    "currency": "USD",
    "value": 2
  },
]
Customer accounts: [
  {
    "accountID": "bd2b81017ecf791cdb3e722eebbe675ae67357d9",
    "maskedAccountNumber": "**4321",
    "routingNumber": "102001017",
    "status": "validated",
    "type": "Checking"
  }
]
Success! The account was validated with micro-deposits

An ACH file was uploaded to a test FTP server at ./testdata/ftp-server/outbound/
total 8
-rw-r--r--  1 adam  staff  1900 Jul 10 10:17 20200710-071000301.ach

View all uploaded files with achcli from moov-io/ach.

achcli ./testdata/ftp-server/outbound/*.ach

Uploaded ACH file

Describing ACH file './testdata/ftp-server/outbound/20200710-071000301.ach'

  Origin     OriginName    Destination  DestinationName  FileCreationDate  FileCreationTime
  221475786  Teachers FCU  071000301    FRBATLANTA       200710            1315

  BatchNumber  SECCode  ServiceClassCode  CompanyName     DiscretionaryData  Identification  EntryDescription  DescriptiveDate
  1            PPD      220               Micro Deposits                     MOOVO3S6TA      validation        200710

    TransactionCode  RDFIIdentification  AccountNumber      Amount  Name                    TraceNumber      Category
    22               10200101            654321             15      Jane Doe                221475787457191

  BatchNumber  SECCode  ServiceClassCode  CompanyName     DiscretionaryData  Identification  EntryDescription  DescriptiveDate
  2            PPD      220               Micro Deposits                     MOOVO3S6TA      validation        200710

    TransactionCode  RDFIIdentification  AccountNumber      Amount  Name                    TraceNumber      Category
    22               10200101            654321             25      Jane Doe                221475783240158

  BatchNumber  SECCode  ServiceClassCode  CompanyName  DiscretionaryData  Identification  EntryDescription  DescriptiveDate
  3            PPD      225               Jane Doe                        MOOVO3S6TA      validation        200710

    TransactionCode  RDFIIdentification  AccountNumber      Amount  Name                    TraceNumber      Category
    27               10200101            654321             40      Jane Doe                221475781875397

  BatchCount  BlockCount  EntryAddendaCount  TotalDebitAmount  TotalCreditAmount
  3           2           3                  40                40

Next Steps

Read over our PayGate documentation for configuration files, api and admin endpoints, ACH details and more information.

Getting Help

channel	info
Project Documentation	Our project documentation available online.
Twitter @moov	You can follow Moov.io's Twitter feed to get updates on our project(s). You can also tweet us questions or just share blogs or stories.
GitHub Issue	If you are able to reproduce a problem please open a GitHub Issue under the specific project that caused the error.
moov-io slack	Join our slack channel (#paygate) to have an interactive discussion about the development of the project.

Supported and Tested Platforms

• 64-bit Linux (Ubuntu, Debian), macOS, and Windows

Contributing

Yes please! Please review our Contributing guide and Code of Conduct to get started! Checkout our issues for first time contributors for something to help out with.

Paygate includes several "long" tests which spawn Docker containers, make requests over the internet, and perform more complicated tests. To skip these long tests add the -short flag to go test.

This project uses Go Modules and uses Go 1.14 or higher. See Golang's install instructions for help setting up Go. You can download the source code and we offer tagged and released versions as well. We highly recommend you use a tagged release for production.

Further Reading

• The default banking-as-a-service platform will be developer-first

Test Coverage

Improving test coverage is a good candidate for new contributors while also allowing the project to move more quickly by reducing regressions issues that might not be caught before a release is pushed out to our users. One great way to improve coverage is by adding edge cases and different inputs to functions (or contributing and running fuzzers).

Tests can run processes (like sqlite databases), but should only do so locally.

Each PR should increase the overall coverage, if possible. You can run make cover-test to save a coverage profile and make cover-web to open the HTML view in your default browser.

License

Apache License 2.0 See LICENSE for details.

Google Cloud Run Button

paygate's Issues

files: setup SFTP controller for periodic refreshing

The SFTP files need to be uploaded and downloaded, which means we need logic behind that and a controller to manage each individual network operation.

This will use the SFTP code from #88

transfers: require disclaimer approval

Paygate needs to ensure certain disclaimers are approved before allowing a Transfer to be created. These are legal agreements for each customer.

Should there be admin endpoints for modifying disclaimers?

POST /depositories/{depositoryId}/micro-deposits (submit micro deposits endpoint)

I didn't fill this endpoint before, but #18 (comment) clarifies it a bit.

Request
POST /depositories/{depositoryId}/micro-deposits

{
  "amounts": [ 0.03, 0.02 ]
}

Response (Success)
OK 200

Response (Error)

{
  "error": "message"
}

Thoughts / Questions

• Support X-Idempotency-Key.
• How many attempts should be allowed?
• Should we record success and failures?
• Can there be multiple attempts against a depository?
  • Could a request be canceled, refunds issued and a new series of deposits are made?
• How many amounts? Always 3? 2 deposit / 1 withdraw?

I think we should add a new sqlite table:

create table micro_deposits(
  micro_deposit_id primary key,
  depository_id,
  amounts, // 0.02,0.03,-0.01
  successful_at datetime, 
  created_at datetime
)

transfers: support reoccurring TEL and WEB transfers

After disabling those reoccurring transfers in this commit this issue is to write back in support for them. We need to collect a schedule from clients in order to properly make authorized transfers in the future. Currently there's no format proposed for the schedule logic.

Often a schedule could be "for N weeks on every Monday" or "15th of every month".

pkg/idempotent: create redis implementation

From the X-Idempotency-Key issue (#15 (comment)) we want to implement a redis implementation of idempotent.Recorder.

Can we run an inmem redis for tests? I don't know off hand what's available.

Create transfers for SEC CODE WEB

Create a new function for SEC Code WEB for transfers.

See createPPDBatch as an example.

depositories: check FED for routing number

We should be checking our FED service on any routing number that's submitted to paygate. This helps ensure data validity.

PATCHing an entry with multiple key/value pairs only applies the first pair

Here's what exists in the database:

curl -X GET http://localhost:8082/depositories/eb7c9914cfc21eaf2ba2dbd517a1910a17a2b039 -H 'x-user-id: taylor' -H "Content-Type: application/json"           

{"id":"eb7c9914cfc21eaf2ba2dbd517a1910a17a2b039","bankName":"BBT","holder":"My Company,llc","holderType":"individual","type":"checking","routingNumber":"051504597","accountNumber":"0001027028","status":"unverified","metadata":"Payroll","created":"2019-06-05T01:22:33Z","updated":"2019-07-03T22:41:34Z"}

But when trying to update several key/value pairs of the entry, only the first one gets applied:

curl -X PATCH http://localhost:8082/depositories/eb7c9914cfc21eaf2ba2dbd517a1910a17a2b039 -H 'x-user-id: taylor' -H "Content-Type: application/json" --verbose --data '{"bankName":"New bank name","holder":"Taylor","type":"savings"}'

*   Trying ::1:8082...
* TCP_NODELAY set
* Connected to localhost (::1) port 8082 (#0)
> PATCH /depositories/eb7c9914cfc21eaf2ba2dbd517a1910a17a2b039 HTTP/1.1
> Host: localhost:8082
> User-Agent: curl/7.65.1
> Accept: */*
> x-user-id: taylor
> Content-Type: application/json
> Content-Length: 63
> 
* upload completely sent off: 63 out of 63 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Date: Wed, 03 Jul 2019 22:42:32 GMT
< Content-Length: 328
< 

{"id":"eb7c9914cfc21eaf2ba2dbd517a1910a17a2b039","bankName":"New bank name","holder":"My Company,llc","holderType":"individual","type":"checking","routingNumber":"051504597","accountNumber":"0001027028","status":"unverified","metadata":"Payroll","created":"2019-06-05T01:22:33Z","updated":"2019-07-03T22:42:32Z"}

* Connection #0 to host localhost left intact

I'm using the latest docker images

X-Idempotency-Key support

Idempotent key in the header which expires after 24 hours. These strings should contain enough entropy for to not collide with each other in your requests.

We need to support this somehow. Redis?

support pagination in api endpoints

Our API docs mention offset/limit and startDate/endDate params used for pagination, but our code doesn't support that. This issue is to wire that support in.

Docs: https://api.moov.io/#operation/getTransfers

transfers: How do we store TEL authorization?

According to NACHA's guidelines for TEL transfers we need to store authorization (ideally audio recorded) from the customer for two years. This is part of their audit requirements.

micro-deposits: include in merged ACH files for ODFI upload

Paygate needs to support including micro-deposits in the ACH files which are uploaded to their ODFI (the FI you partner with for ACH). This is needed so the transfers post to external accounts.

depositories: unhardcode micro-deposit amounts

Now that we have our Accounts service (really a general ledger) we can remove the hardcoded micro-deposit amounts that are shared between paygate and apitest. Instead apitest should do a lookup and see what was posted as random amounts by paygate.

Paygate should make random deposits and credits (which balance) against the accounts to validate the Depository.

record ofac blocks, lookup durations and histogram of match %

I had written this down when working on some OFAC code on a plane. We likely will want to record our OFAC performance, but for now it could be metrics to casually inspect how the searches are returning and performing.

In api/openapi.yaml, consider changing tag name Customers to Receivers

The term 'receiver' is more correct for indicating the other side of a transfer from an Originator.

transfers: YYYDetail (i.e. WEBDetail) sub-objects are often copied incorrectly

jq -n --arg orig $ORIGINATOR_ID --arg origDep $DEPOSIT_ID1 --arg rec $RECEIVER_ID --arg recDep $DEPOSIT_ID2 '{"transferType": "push", "amount": "USD 99.99", "originator": $orig, "originatorDepository": $origDep, "receiver": $rec, "receiverDepository": $recDep, "description": "Loan Pay", "standardEntryClassCode": "WEB", "sameDay": false, "CCDDetail": { "paymentInformation": "test payment" }, "WEBDetail": { "paymentInformation": "test payment", "paymentType": "single" } }' | curl -k -o - -s  --header "X-User-Id: $USER_ID" --request POST --url https://moov-paygate.$SANDBOX/transfers --data @- | jq .
{
  "error": "createACHFile: WEB: createWEBBatch: reoccurring WEB transfers are not supported yet"
}

In the detail above the WEB type is "single". However, I get an error saying reoccurring WEB transfers are not support.

Are any WEB type transfers supported yet?

docs: godoc, contributing guide, code of conduct

What were you trying to do?

As a new user I was trying to contribute to this project, but was looking for a guide to walk through the process.

What did you see?

Not much of a guide. The project onboarding should be more straightforward.

This includes godoc.

receivers: reject duplicate emails

We need to check for an email address already existing in our database. Like auth it probably makes sense to store a clean_email field in our database that has punctuation stripped out and a unique index on the database.

build: add FTP and SFTP servers in docker-compose

We should launch our docker-compose setup with an FTP and SFTP (ssh file transfer protocol) servers running so paygate can show the async file transfer logic. Instead paygate currently spams the log with errors:

{"caller":"file_transfer_async.go:215","startPeriodicFileOperations":"Starting periodic file operations","ts":"2019-07-06T00:47:05.870453375Z"}
...
{"caller":"file_transfer_async.go:271","downloadAndProcessIncomingFiles":"error downloading files into /storage/downloaded469047369","error":"downloadAllFiles: problem with 323075822 file transfer agent init: EOF","ts":"2019-07-06T00:49:05.879605236Z"}

There are commands in the makefile, make start-ftp-server and make start-sftp-server we can use that as a starting point for the docker-compose file. The only complication is that inbound and returned files are deleted, so you’d only see paygate process files in the first iteration of its sftp loop.

This also ties in with #147 as to how we would configure this inside the docker-compose file.

Query OFAC on Customer/Receiver information

Once we have OFAC's HTTP server up and running paygate will need to query it. The Customer.Metadata and Originator.Metadata should be checked (maybe other fields?) and the request/transfer rejected if a strong match is found.

Refer to a generated client or api documentation for the exact call. (Not ready yet)

Example endpoint: https://api.moov.io/v1/ofac/customers/306

files: option to group into separate debit and credit files

Some Financial Institutions require ACH files be sent to them which only contain debits or credits.

I'm not sure of a backing business reason for this, but it's easy enough that we can (and will likely need to) support.

How does the status change for a customer, depository, and transfer ?

Right now the Customer, Depository and Transfer have their own status enums, but there's no support in the API for updating the status. I'm assuming transfers can only happen if all the components are verified.

Does this need to be part of existing endpoints? Admin backend to approve?

Allow calls to Accounts to be disabled

Some customers wish to ignore the accounting side of paygate/accounts and instead use paygate as an SFTP ach file uploader. We should be able to allow this by having a config to disable the calls to accounts

Create transfers for SEC CODE TEL

Create a new function for SEC Code TEL for transfers.

See createPPDBatch as an example.

files: sqlite/mysql support for localFileTransferRepository

Right now the fileTransferRepository is hardcoded to be localFileTransferRepository (test values) and we should support sqlite/mysql as another data store.

spike: Support a file based config for paygate

We're starting to see a lot of configuration options for paygate, with more everyday, and environmental variables get annoying to configure after adding 10+ of them. We could switch to a file based config that makes it a bit easier to configure paygate.

In the future we might support configuration for each SEC code (PPD vs IAT, etc), velocity, ABA routing tables, etc. These would be difficult and error prone to configure with environmental variables alone.

Personally, we should pick YAML or TOML as the format.

docs: Add a section for creating each SEC code

After adding support for CCD, TEL, WEB and other SEC codes our docs need sections for HTTP examples to create each. The SEC codes will likely have specifics to explain within paygate and expectations (auditing, authorization, return handling, etc)

ACH file values for /depositories/{id}/micro-deposits

Part of #8 is to start creating ACH files. For micro deposits this would be multiple small (<$1) deposits. Likely two credit and one debit?

This issue is similar to #29 and lots of the code will be re-used, but this issue tracks any work specific to micro deposits.

Support (SFTP) file transfers for reading and writing

We need to support (SFTP) file transfer for files after they're created and ultimately reading inbound and returned files.

proposal: Tie ACH and OFAC boot checks to admin servlet status code

Rather than calling panic on startup if our dependencies aren't healthy we should have the admin servlet be unhealthy. That way a dependency can be down and paygate launches.

provide env vars for flag arguments

We kinda/sorta follow the 12 factor app model and have everything that can be configured in a service configured by environment variable. It is generally easier and more standard than setting configs via launch flags. (Not all apps handle flags the same way.)

As such it would be nice if flags like: -http.addr :80 -log.format json

could also be set via environment variable.
HTTP_ADDR=:80
LOG_FORMAT=json
etc.

handle ISO8601 for time.Time JSON values

See https://github.com/moov-io/api/issues/33 and moov-io/base#7

Refactor Customer to Receiver

The codebase and API utilize the ACH term Originator for the company or individual that are generating the credit/debit transaction against a "Customer". Using ACH terminology the "Customer" should be called a "Receiver" throughout the code base and API.

The background is that "Originator" was previously labelled "Account" which had little to no meaning besides an Account had Customers. An Originator has a Receiver.

transfers: reverse Returned transfers against Accounts

We need to reverse the accounting done when a transfer is returned. This is to keep balances correct as the initial transfer never occurred.

Accounts added support for this.

ACH file values for POST /transfers

Part of #8 is to actually create the ACH files and send them over to our ACH service. To do this we need to figure out the specific values.

For a transfer, are we just supporting Push for now? Wade has mentioned Pull is more complicated.

Here's the values I want to confirm:

https://github.com/adamdecaf/paygate/blob/create-ach-file/transfers.go#L686

Batch

• ServiceClassCode: Credits 220 / Debits 225 (Push would be Credit?)
• StandardEntryClassCode: I defaulted to PPD just to get something working
• CompanyIdentification: 9 digit FEIN number
• EffectiveEntryDate: End of Day today? Tomorrow?

EntryDetails

• TransactionCode: 22 / 23 / 27 / 28 / 32 / 33 / 37 / 38
  • I think this can be handled by a fancy switch, Push is Credit?
• IdentificationNumber: Do we have API support to capture this?
• TraceNumber: How do we want to manage/generate this?

build: integrate safesql into CI pipeline

safesql is a tool from Stripe that protects against SQL injections. We should include that as a tool which we run over our codebase on every build and pull request.

transfers: deduplicate creating a transfer against returned files

Before creating a new transfer do we need to deduplicate that against returned files? I could see someone re-creating a transfer the a day or two after the initial one because the transfer failed, but in reality the file was returned and we may not have notified them yet.

Consider generating code from API definition

I have found it nice to generate code from API definitions (as opposed to the opposite direction). It looks like you might be manually writing each here right now? I would take a good look at generating from protobufs... It is a very nice way of defining services. You get benefits of gRPC + the swagger/REST stuff for free (for clients who like REST).

If you havent already looked into Google's API design docs, I think they are top-notch: https://cloud.google.com/apis/design/

Just some ideas...

can I submit transaction for $XX against account YY

business logic of "can I submit transaction for $XX against account YY"

• lives in paygate, talks to GL
  • maybe pkg/acctcheck package? (useful for other apps?)

transfers: support IAT details

We need to support creating IAT ach files in paygate. This would include all the IAT specific details (see ACH's IAT EntryDetail).

These should probably all be in one JSON object off the Transfer json (similar to WEBDetails):

{
		FromAddress: "123 Maple Street", FromCity: "Anytown",
		FromState: "NY",
		FromPostalCode: "07302", FromCountryCode: "US", FromBankName: "Cross River Bank", FromIdentificationQualifier: "01", FromBankCountryCode: "US", ToAddress: "456 Main Street",
		ToCity: "New York",
		ToState: "NY",
		ToPostalCode: "11201",
		ToCountryCode: "US",
		ToBankName: "Chase Bank",
		ToIdentificationQualifier: "01",
		ToBankCountryCode: "US",
		UltimateReceiverName: "John Brit",
		UltimateReceiverAddress: "12 Queens Way",
		UltimateReceiverCity: "London",
		UltimateReceiverState: "Essex",
		UltimateReceiverPostalCode: "GX1234",
		UltimateReceiverCountryCode: "GB",
		FCBName: "Some Foreign Bank",
		FCBIdentification: "XYZ234",
		FCBIdentificationQualifier: "02",
		FCBCountryCode: "GB"
	}

spike: paygate -> QLedger interaction

We need to experiment and see if QLedger would work for us to use as database for GL debits and credits. They have a Go library, but @adamdecaf has a couple outstanding changes. (We could fork if needed.)

A few notes:

• we won't expose QLedger to the public
• reports are off another API service we write // later, don't worry about this now
• "GL rules" are applied to debit/credit each GL account
  • How custom does this get for each FI?

Example A - New $500 ACH deposit into Non-interest bearing checking account

Customer initiates a $500 ACH to another bank checking account.
Customer checking account number is used to determine the correct customer account that increases by $500.
ACH deposit gets put into a batch to go to the Fed clearing house to be withdrawn from other financial institution based on the routing number etc (Funds are not “available” until transaction clears through the system which takes about a day/float).
All the customer non-interest bearing checking accounts are totaled up in GL/Call Report Code RCON6631 as a liability on the Call Report balance sheet line 13.
The $500 deposit will also be shown on Schedule RC-E Deposit Liabilities total RCON2200 and detailed in 1. Column A as an individual transaction account GL/Call Report Code RCONB549
The $500 deposit will also be included in Schedule RC-O Other Data for Deposit Insurance and FICO Assessment RCONF049
No Interest paid
Call Report Income Statement - Service Fees could be charged to the following - Non-Interest Income 5b - Service Changes on Deposit Accounts - RIAD4080, 5.f. Net Servicing fees - RIADB492, 5.l. Other Non-Interest Income (See Schedule RI-E Explanations - 5.l.1.f. Bank card and credit card interchange fees - RIADF555, 5.l.1.g. Income and Fees from wire transfers - RIADT047, 5.l.2.a. Other non-interest expense - Data processing expense RIADC017.

Example B - New $500 ACH deposit into an Interest bearing checking account

Customer initiates a $500 ACH to another bank checking account
Customer checking account number is used to determine the correct customer account that increases by $500.
Check gets put into a batch to go to the Fed clearing house to be withdrawn from other financial institution based on routing number etc (Funds are not “available” until check clears through the system which takes about a day/float).
All the customer interest bearing checking accounts are totaled up in GL/Call Report Code RCON6636 as a liability the Call Report balance sheet line 13.
The $500 deposit will also be shown on Schedule RC-E Deposit Liabilities total RCON2200 and detailed in 1. Column A as an individual transaction account GL/Call Report Code RCONB549
The $500 deposit will also be included in Schedule RC-O Other Data for Deposit Insurance and FICO Assessment RCONF049
Interest that accrues on this account will be included in Interest Accrued and unpaid on Deposits - RCON3645.
Fees paid will go into Other Expenses Accrued and Unpaid - RCON 3646
Income Statement - Service Fees could be charged to the following - Call Report Income Statement - Non-Interest Income 5b - Service Changes on Deposit Accounts - RIAD4080, 5.f. Net Servicing fees - RIADB492, 5.l. Other Non-Interest Income (See Schedule RI-E Explanations - 5.l.1.f. Bank card and credit card interchange fees - RIADF555, 5.l.1.g. Income and Fees from wire transfers - RIADT047, 5.l.2.a. Other non-interest expense - Data processing expense RIADC017.

Bob's notes

(From Bob Smith on 2019-01-16)

Wade - these are the “rules” from the banking Call Report.  I only pulled the lines from the balance sheet and income statement that are used in a deposit flow.  Please refer to the FDIC Call report that I sent earlier from NXT.  The next email will have two examples of $500 deposit into a non-interest bearing checking account and one into an interest bearing checking account.  Let me know what you think, questions, what will Adam need...

Thanks!

Bank Deposit - Accounting flow for deposits, related fees and accrued interest

Bank Call Report -

Income Statement (potentially relevant GL Codes)

2a - Interest Expense of Deposits
1. Transaction Accounts (Interest bearing checking, savings, NOW) RIAD4508
2. NonTransaction Accounts (includes MMDA’s) RIAD0093

5 - Non-interest Income
5.b. Service Charges on deposit accounts - RIAD 4080
5.f. Net Servicing Fees - RIADB492
5.l. Other Non-interest Income - RIADB497

Schedule RI-E Explanations - Other Non-Interest Income Itemized
1.f. Bank card and credit card interchange fees.- RIADF555
1.g. Income and Fees from Wire Transfers - RIADT047
2.a. Data Processing Expense - RIADC017


Balance Sheet - from Call Report

Deposits
13a. In Domestic offices (roll up into) RCON2200
13a1 Non-Interest Bearing (includes demand, time, savings) - RCON6631
13a2 Interest Bearing - RCON6636

Following GL’s roll up into non-interest bearing and interest bearing
Schedule RC-E- Deposit Liabilities
1. Individuals, Partnerships, and corporations
Column A - Transaction Accounts - RCONB549
Column C - Non-Transaction Accounts - RCONB550
4. Commercial Banks and other Deposit Institutions in US -
Column A - Transaction Accounts - RCONB551
Column C - Non-Transaction Accounts - RCONB552
5. Banks in Foreign Countries -
Column A - Transaction Accounts - RCON2213
Column C - Non-Transaction Accounts - RCON2236

(Second page of this schedule)
2. Components of Non-transactional accounts
2a Savings Deposits:
2a1 - Money Market Deposit Accounts RCON6810
2a2 - Other Savings Deposit - RCON0352


Other Liabilities - RCON2930
Schedule RC - G - Other Liabilities
1.a Interest Accrued and unpaid on deposits - RCON3645
1.b Other expenses accrued and unpaid - RCON3646


Schedule RC - O - Other Data for Deposit Insurance and FICO Assessments
1a Deposits accounts of $250,000 or less
Dollar amount. - RCONF049
Number of accounts - RCONF050
1b Deposit accounts of more than $250,000
Dollar amount - RCONF051
Number of accounts - RCONF052

Adam - I have a CFO at a bank reviewing the above info.  Should hear back next week sometime.  I will also send an example ACH deposit transaction.  Please let me know what additional details you need...  Thanks!

---

Bob Smith [9:58 AM]
Adam - below are two account summary logs for two transactions.  Please review and let me know how much more you will need.  My guess is for our product, all we will need is to send the funds to RCON6631 (non-interest bearing transaction accounts, demand, time, savings deposit accounts) or RCON6636 (interest bearing transaction accounts, demand, time, savings deposit accounts).  Hope this makes sense!  Let me know...

https://cdr.ffiec.gov/public/ManageFacsimiles.aspx

HTTP endpoints for file-transfer configs

We should expose HTTP endpoints for SFTP, cutoff times, and ACH file transfers (uploads). This allows back office tools to inspect and modify them.

First, let's create a read endpoint that masks any passwords. If there are requests for more let's add those.

ach service interaction

As part of some of the transfer routes we need to create ACH files in our ach service.

https://api.moov.io/#tag/Files

Steps

• Implement ACH service calls to create, validate, and build file
• Figure out entire ACH json payload
• Store ACH fileId on transfers table

microDeposits: delete ACH files after creation

Once paygate creates the ACH files for micro-deposits and whatever process takes those for sending to the Fed we should delete them. It'll help cleanup space.

The process that reads the files and sends them off to the Fed would probably be a better service to delete the files.

sqlite persistence implementation

We need to replace the in-memory persistence with a complete sqlite storage layer. This will make it much easier for local development and get us further down the line to a v1 product.

Look our auth project for most of the sqlite setup code. The connections metric is in main.go.

Later on we can make a shared lib, but not now.

missleading log message

paygate/internal/database/mysql.go

Line 59 in 7b9f43a

my.logger.Log("sqlite", fmt.Sprintf("migration #%d [%s...] changed %d rows", i, slug, n))

When doing the mysql migration - it say's sqlite instead of mysql.

reject Depositories that don't exist in GL

When a Depository is created we need to check GL and confirm the account exists. If it doesn't then we need to reject the Depository (or Transfer). If we reject a Transfer then send back a return code:

ACH Return Codes
R01 Insufficient Funds
R02 Account Closed
R03 No Account/Unable to Locate Account
R04 Invalid Account #

transfers: support creating CCD transfers

Similar to TEL or WEB we need to support creating CCD files in paygate (as Transfers). We'll likely need a specific CCDDetail object on a Transfer json request.

database: Support MySQL

We have a potential customer who wants to use MySQL as the backing store for paygate. This means we'll need to adopt the SQLite code to also handle mysql.

There's a popular and supported MySQL driver we can use and a proper migration library also.

I was looking for an ORM and found beego/orm, which supports sqlite and mysql (among others also).

We can launch a Docker container with ory/dockertest: https://docs.docker.com/samples/library/mysql/

ACH WEB support

This isn't handled by the endpoints or persistence now. We need to handle this.