No offense, but saying this is 'automated code review' and specifically mentioning something like "comply with regulatory standards" is missing the point. The whole point of these regulatory standards (such as SOX) is to put an additional human in the loop, so that a single engineer can't do something obviously bad with people's credit cards, or whatever it is.
Also, given that this is glorified linting, it should be run before code review. Any code review that focuses on issues that can be picked up via a linter isn't actually a review. Code reviews are a higher level analysis.
I agree that running the linter before checking the code into version control would be even better (and in fact we have an API that allows that), but our goal with this tool was to interrupt the development workflow as little as possible. Hence checking code in the version control system seemed a reasonable approach. Also, today many teams use a pull-request based workflow, where code does not get merged into the main branch before it is reviewed (Github pull-review integration is coming soon btw).
And of course the tool can't fully automate code review (since a linter can never know the intent of the programmer), but it can help you to already weed out many problems before a reviewer looks at the code, thus giving you more time to find the really interesting / dangerous bugs in the code.
SOX isn't to put an additional human in the loop. It certainly isn't to prevent a single engineer from doing anything.
SOX is there to force managers and every down the line to verify what they do is accurate, where they said things are is accurate and who has access to what is accurate.
It's more of an audit and legally verifying so that if something goes wrong, people can be blamed.
Also, given that this is glorified linting, it should be run before code review. Any code review that focuses on issues that can be picked up via a linter isn't actually a review. Code reviews are a higher level analysis.